Disks inside of VMs

[ron r bell]

I have the following:

HPUX 11.31 Sep09

On VM HOST:
# swlist |grep -i "integrity vm"
T2767CC B.04.10 Integrity VM
VMGuestLib B.04.10 Integrity VM Guest Support Libraries
VMGuestSW B.04.10 Integrity VM Guest Support Software
VMKernelSW B.04.10 Integrity VM Kernel Software
VMMGR A.04.00.00.70 HP Integrity VM Manager


On VM:
$ swlist |grep -i "integrity vm"
HPVM-Guest B.04.10 Integrity VM Guest
VMGuestLib B.04.10 Integrity VM Guest Support Libraries
VMProvider B.04.10 WBEM Provider for Integrity VM

I created a couple of VMs with avio_stor and some I created with one disk and then used hpvmmodify to add more disks.

Everything is fine... the ones that were created/modified via the command line... the persistent disk path inside the VMGues match exactly the persistent disk path on the VMHost.

For example,
[Storage Interface Details]
Guest Physical
Device Adaptor Bus Dev Ftn Tgt Lun Storage Device
======= ========== === === === === === ========= =========================
disk avio_stor 0 0 0 0 0 disk /dev/rdisk/disk35
disk avio_stor 0 0 0 1 0 disk /dev/rdisk/disk36
disk avio_stor 0 0 0 2 0 disk /dev/rdisk/disk49
disk avio_stor 0 0 0 3 0 disk /dev/rdisk/disk50
disk avio_stor 0 0 0 4 0 disk /dev/rdisk/disk52


disk35 and disk36 were created via the command line and show up on the VMGuest as disk35 and disk36. disk49,50,52 were added via SMH, they show up on the VMGuest as disk42,44,46.

Can someone tell me why some show up with the same persistent disk name and others do not?

This is the same on all four VMs that I created. All disk allocated via command line match. All disks allocated from SMH do not.

Thanks,
Ron

[Steven E. Protter]

Shalom Ron,

What HP told me is how they show up depends on the process used to create them.

But it seems you are saying you used avio_stor to create them all and were consistent.

ioscan -m dsf

Might provide some insight into what you are seeing.

I'm building HPVM infrastructure right now.

SEP

[ron r bell]

Hi Steven,

below are the ioscans on the VM:

$ ioscan -nNfC disk
Class I H/W Path Driver S/W State H/W Type Description
===================================================================
disk 35 64000/0xfa00/0x10 esdisk CLAIMED DEVICE HP Virtual Disk
/dev/disk/disk35 /dev/disk/disk35_p2 /dev/rdisk/disk35 /dev/rdisk/disk35_p2
/dev/disk/disk35_p1 /dev/disk/disk35_p3 /dev/rdisk/disk35_p1 /dev/rdisk/disk35_p3
disk 36 64000/0xfa00/0x11 esdisk CLAIMED DEVICE HP Virtual Disk
/dev/disk/disk36 /dev/rdisk/disk36
disk 42 64000/0xfa00/0x17 esdisk CLAIMED DEVICE HP Virtual Disk
/dev/disk/disk42 /dev/rdisk/disk42
disk 44 64000/0xfa00/0x18 esdisk CLAIMED DEVICE HP Virtual Disk
/dev/disk/disk44 /dev/rdisk/disk44
disk 46 64000/0xfa00/0x19 esdisk CLAIMED DEVICE HP Virtual Disk
/dev/disk/disk46 /dev/rdisk/disk46



$ ioscan -m dsf
Persistent DSF Legacy DSF(s)
========================================
/dev/rdisk/disk35 /dev/rdsk/c50t0d0
/dev/rdisk/disk35_p1 /dev/rdsk/c50t0d0s1
/dev/rdisk/disk35_p2 /dev/rdsk/c50t0d0s2
/dev/rdisk/disk35_p3 /dev/rdsk/c50t0d0s3
/dev/rdisk/disk36 /dev/rdsk/c50t1d0
/dev/rdisk/disk42 /dev/rdsk/c50t2d0
/dev/rdisk/disk44 /dev/rdsk/c50t3d0
/dev/rdisk/disk46 /dev/rdsk/c50t4d0


Thanks, Ron

[Tim Nelson]

If the 15 year history of "SAM" and now "SMH" were to dictate then I would say that anything is possible whenn using SMH..( yuck, never used it, never will )

[ron r bell]

Tim, I agree with you. I created the VMs but other admins (client site) manage them. They are new to HPUX and rely on SMH to help ease the transition.

[Eric SAUBIGNAC · Accepted solution]

Bonsoir Ron,

Unless I missunderstood a point in your question, I see very, very, few reasons that could explain that a disk has the same dsf in a VM Guest than in the VM Host.

Under 11iv3, new disks are numbered in the order they come. For example, see this thread http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1413783

And as far as I know, disk recognition is also based on disk's signature.

So, not sure, but what could explain that you have same dsf between VM Guest and VM Host (disk35 & disk36) is that you have installed the VM from an ignite image of the VM Host : disk already indentified before the creation of the host's ignite image, will be identified as same in the guest.

Or by chance ... but I really don't think so ;-)

Make a test : create a new disk on your storage area, identify its dsf on the VM Host, present it to the VM Guest from command line. I am pretty sure you will not have the same dsf in the VM Guest than in the VM Host. Whatever you use command line or SMH.

You can also force the numbering of the disk with ioinit, but I guess you did not.

Hope this help

Eric

[ron r bell]

Eric,

You are exactly right...

I did create the VMGuests from a drd clone of the VMHost. I didn't think to mention that.
The original disks that I allocated to the VMGuests were already presented to the VMHost when I did the clone.

The newly added disks (for each VMGuest) now are following the same pattern within the VM(disk42,44,etc).

You are the man!

[ron r bell]

Thanks to Eric and Steven. Sorry Steven, I should have given you more points. You did say it depended on how I created the VMs.

Thanks guys,
Ron