How to attaching disks to a integrity vm

[iazuarah]

Hi,

I have a Superdome 2 16s server. In this server i had 2 npars and each one, will define several vm's. I'm using the last release for Integrity VM on the npar:

vmGuestLib            B.06.20        Integrity VM vmGuestLib
vmGuestSW             B.06.20        Integrity VM vmGuestSW
vmKernel              B.06.20        Integrity VM vmKernel
vmOVMMSW              B.06.20        Integrity VM vmOVMMSW
vmProvider            B.06.20        WBEM Provider for Integrity VM vmProvide
vmVirtProvider        B.06.20        Integrity VM vmVirtProvider

My external disks comes from a Hitachi Storage Server that is connected to different fiber channel hbas installed in different IOX.

This fc hbas are managed by the Npar2:

sd16dom2_npar2# ioscan -fnkC fc
Class     I  H/W Path  Driver S/W State   H/W Type     Description
=================================================================
fc        0  42/0/0/2/0/0/0/5/0/0/0  fclp   CLAIMED     INTERFACE    HP AT094-60001 PCIe Fibre Channel 2-port 8Gb FC/2-port 10GBE Combo Adapter
                      /dev/fclp0
fc       20  45/0/2/0/0/0/0/5/0/0/0  fclp   CLAIMED     INTERFACE    HP AT094-60001 PCIe Fibre Channel 2-port 8Gb FC/2-port 10GBE Combo Adapter
                      /dev/fclp20

When i run the ioscan command on my Npar2, i can discover the disks that will assign to the vm1. In this case are 4 disks (disk21, disk22, disk23, disk24).

NPAR2

sd16dom2_npar2# hpvmstatus
[Virtual Machines]
Virtual Machine Name VM #  Type OS Type   State     #VCPUs  #Devs  #Nets  Memory
==================== ===== ==== ======= ========= ====== ===== ===== =======
infisrv                                       1   SH    HPUX      On (OS)        6              2             1   48 GB

sd16dom2_npar2# ioscan -fnC disk | grep HITACHI

disk     17  45/0/2/0/0/0/0/5/0/0/0.1.73.0.0.0.0   sdisk   CLAIMED     DEVICE       HITACHI OPEN-V
                         /dev/dsk/c10t0d0   /dev/rdsk/c10t0d0
disk     18  45/0/2/0/0/0/0/5/0/0/0.1.73.0.0.0.1   sdisk   CLAIMED     DEVICE       HITACHI OPEN-V
                         /dev/dsk/c10t0d1   /dev/rdsk/c10t0d1
disk     19  45/0/2/0/0/0/0/5/0/0/0.1.73.0.0.0.2   sdisk   CLAIMED     DEVICE       HITACHI OPEN-V
                         /dev/dsk/c10t0d2   /dev/rdsk/c10t0d2
disk     20  45/0/2/0/0/0/0/5/0/0/0.1.73.0.0.0.3   sdisk   CLAIMED     DEVICE       HITACHI OPEN-V
                         /dev/dsk/c10t0d3   /dev/rdsk/c10t0d3

sd16dom2_npar2# ioscan -m dsf

/dev/rdisk/disk21        /dev/rdsk/c10t0d1
                         /dev/rdsk/c12t0d1
/dev/rdisk/disk22        /dev/rdsk/c10t0d3
                         /dev/rdsk/c12t0d3
/dev/rdisk/disk23        /dev/rdsk/c10t0d0
                         /dev/rdsk/c12t0d0
/dev/rdisk/disk24        /dev/rdsk/c10t0d2
                         /dev/rdsk/c12t0d2

What is the recommended procedure for assign these disks to the vm 1 ??. I was reading the Integrity VM V 6.2 Administration Guide, but i have some dudes about the storage assigment to the vm's. I'm interesting in use the attached i/O method because i don't want to share these disks to others vm's on the npar2. In fact, i was thinking if is convenient to assign the 2 fc hba's hardware paths to the vm 1 and then discover directly these 4 disks since the vm 1 os ??. it's possible or is not necessary ??.

Thank's in advance

Ivan

[Jason_L]

There are tradeoffs as documented in the VM User Guide as to which "backing" method you choose to use.

For instace file backing although highly portable is not a good choice for high I/O devices.  More suitable for DVD etc.

Then you have LVM backed storage.  Where basically you create a volume group and logical volume and assign to a VM.  these are better in performance than file backed, yet offer some versatility - like naming conventions.  This makes each LV easy to identify as belonging to a VM.

Then there is disk backed storeage.  Disk backed storage is even higher in performance than both LV and file backed storage.  You basically assign the VM a "raw" disk device,which then shows up as a disk with IOSCAN from the VM guest.

With all of the above you will need to use the AVIO_STOR device

I believe 6.1 or 6.2 also introduced the NPIV feature allowing you to perform direct assignement of a SAN based volume to a VM guest.  This would in theory be the best performer of the group, however I do not have much experience with this method.  Most of my experiences are with the "raw" disk backed storage devices assigned to the VM guest.  This gives you some granularity of control, but also offers good performance.

Bottom line the higher you go up the I/O stack on the VM host, the more performance hit you take on the guest.  Which is why I would NOT recommend file backed storage for applications etc.

As for the exact commands, there are many examples in the config guide, once you decide which method you would prefer.

[Jason_L]

A pretty good read on the NPIV.

http://h20195.www2.hp.com/V2/GetPDF.aspx%2F4AA3-9894ENW.pdf

Link is for 6.1 version, I am looking for the 6.2 version as well.

"What is the recommended procedure for assign these disks to the vm 1 ??. I was reading the Integrity VM V 6.2 Administration Guide, but i have some dudes about the storage assigment to the vm's. I'm interesting in use the attached i/O method because i don't want to share these disks to others vm's on the npar2. In fact, i was thinking if is convenient to assign the 2 fc hba's hardware paths to the vm 1 and then discover directly these 4 disks since the vm 1 os ??. it's possible or is not necessary ??."

With the legacy AVIO you had to present ALL of the storage to the VM host, then either use file, LV or RAW backed storage and assign to the VM guest.  With NPIV, you create a virtual HBA and you assign the HBA to the VM guest.  This will provide the guest with a unigue WWN which you can then zone and provision SAN based volumes.

So yes, if you choose this mentod, you will be able to discover the volumes directly on the guest and there is no need to present the volumes to the host. Be aware though to read through the caveats in the NPIV document.

[iazuarah]

Thank's Jason, your information is very interesting and the NPIV is the best solution for me, but need to cover many prerequisites in hardware an software. By the way, is posible to have a mix environment , using NPIV for some virtual machines and the avio_stor for others ??.

Best Regards

[Dave Olker]

Yes it is possible to mix and match VM storage on VM guests - even on the same VM guest. You can configure an NPIV-based LUN as a boot disk, use AVIO LUNs as data disks, use LVM logical volumes, file-based backing stores, NFS-based backing stores, etc.  There is no requirement to use only one storage type.

I prefer to use NPIV whole LUNs or AVIO whole LUNs as they perform better than LVM, file, NFS-based backing stores.

Dave

[iazuarah]

ok, perfect.

By the way, i'm triying to attach a disk using the avio procedure:

# hpvmmodify -p 1 -a disk:avio_stor::disk:/dev/rdisk/disk21

that's correct ??.

Ivan

[Dave Olker]

Assuming you want to add the whole disk /dev/rdisk/disk21 to guest #1 via AVIO, yes that syntax looks correct.

[iazuarah]

Thanks in advance !!

[iazuarah]

Hi, i'm starting to install the NPIV on my npar and vm. But i'm having a connection problem between the server and client. This is the message:

# /opt/guid/bin/guid_client_prepare -a


NOTE:
 We found Host is configured in /opt/guid/etc/guid.conf. This
may because current machine has been once installed and
configured as a GUID client.  Or user has defined hostname in
guid.conf by CLI tool "guidconfig -h".
 In this case, we only try setting up authentications between
current client and remote GUID servers, which are configured
in HOST.

Install pubkey on GUID server(sd16dom2) succeeded.

Connect to host sd16dom2 failed. ---> NOTE: BOTH SERVERS ARE IN THE SAME SUBNET

ListRange of wwn from GUID server(sd16dom2) failed.

GUIDMGR client preparation accomplished.

Some suggestion ??.

Regards

[Dave Olker]

I assume you have a GUID manager configured at this point and have created a range of WWN values.  You can try manually setting the hostname of the GUID manager using "guidconfig -h" and then see if you can query the GUID manager to display the list of managed WWN ranges:

# /opt/guid/bin/guidconfig -h <hostname of GUID manager>

# /opt/guid/bin/guidmgmt -L wwn

Dave