Creating an EVA snapclone to create/copy IVM guests...

[grahamswilson]

Here is the scenario - I have a 11iv3 IVMv4 host with a 100GB SAN disk presented to it.

I then created a (11iv3) guest - guest A - and gave the 100GB SAN disk to it (as a disk resource rather than a LV one via AVIO_STOR). I then built that guest (via a Golden Image) and shut it down.

Then I created a snapclone of that disk on the SAN (an EVA) and presented it back to the IVM host.

I was hoping to see another single disk which I could then give to another guest - guest B...

However, when I presented the snapclone to the host, the host discovered the disk _but_ it also saw the corresponding service partitions and created the corresponding device files i.e. /dev/disk/diskXX_p1, p2, p3)!!

So in otherwords, instead of simply being able to give this new SAN VDISK to guest B and then start it, it's like the host is being too clever and "seeing" the installation within the original disk and being "helpful" when installing the device files for the clone...

Just wondered if anyone else had seen this behavior and wonder whether this is "correct"? Although I suspect that may be just 'how it is'...

[Duncan Edmonstone · Accepted solution]

Graham,

Yep that's just "how it is" - here's an ioscan from an 11iv3 VM host:

# ioscan -funNC disk
Class I H/W Path Driver S/W State H/W Type Description
===================================================================
disk 7 64000/0xfa00/0x2 esdisk CLAIMED DEVICE HP DG146B B976
/dev/disk/disk7 /dev/rdisk/disk7
/dev/disk/disk7_p1 /dev/rdisk/disk7_p1
/dev/disk/disk7_p2 /dev/rdisk/disk7_p2
/dev/disk/disk7_p3 /dev/rdisk/disk7_p3
disk 8 64000/0xfa00/0x3 esdisk CLAIMED DEVICE HP DG146B B976
/dev/disk/disk8 /dev/rdisk/disk8
disk 9 64000/0xfa00/0x4 esdisk CLAIMED DEVICE HP DG146B B976
/dev/disk/disk9 /dev/rdisk/disk9
disk 10 64000/0xfa00/0x5 esdisk CLAIMED DEVICE HP DG146B B976
/dev/disk/disk10 /dev/rdisk/disk10
/dev/disk/disk10_p1 /dev/rdisk/disk10_p1
/dev/disk/disk10_p2 /dev/rdisk/disk10_p2
/dev/disk/disk10_p3 /dev/rdisk/disk10_p3
disk 19 64000/0xfa00/0xf esdisk CLAIMED DEVICE HP HSV300
/dev/disk/disk19 /dev/rdisk/disk19
/dev/disk/disk19_p1 /dev/rdisk/disk19_p1
/dev/disk/disk19_p2 /dev/rdisk/disk19_p2
/dev/disk/disk19_p3 /dev/rdisk/disk19_p3
disk 20 64000/0xfa00/0x10 esdisk CLAIMED DEVICE HP HSV300
/dev/disk/disk20 /dev/rdisk/disk20
/dev/disk/disk20_p1 /dev/rdisk/disk20_p1
/dev/disk/disk20_p2 /dev/rdisk/disk20_p2
/dev/disk/disk20_p3 /dev/rdisk/disk20_p3
disk 21 64000/0xfa00/0x11 esdisk CLAIMED DEVICE HP HSV300
/dev/disk/disk21 /dev/rdisk/disk21
/dev/disk/disk21_p1 /dev/rdisk/disk21_p1
/dev/disk/disk21_p2 /dev/rdisk/disk21_p2
/dev/disk/disk21_p3 /dev/rdisk/disk21_p3
/dev/disk/disk21_p4 /dev/rdisk/disk21_p4
disk 22 64000/0xfa00/0x12 esdisk CLAIMED DEVICE HP HSV300
/dev/disk/disk22 /dev/rdisk/disk22
/dev/disk/disk22_p1 /dev/rdisk/disk22_p1
/dev/disk/disk22_p2 /dev/rdisk/disk22_p2
/dev/disk/disk22_p3 /dev/rdisk/disk22_p3
/dev/disk/disk22_p4 /dev/rdisk/disk22_p4

disk10 is the VM hosts own boot disks, but disk19, disk20, disk21 and disk22 are all VM guest disks - as you can see, all the partitions are there.

Don't worry about it - just present the whole disk to the VM guest and ignore the slices - the VM guest OS will create its own device files for these slices.

Remember to come up in single user mode for your first boot so you can change hostname and IP addresses.

HTH

Duncan

[Eric SAUBIGNAC]

Bonjour Graham,

It is a normal behavior of HP-UX. And it is working this way since the first version on Itanium. As soon as HP-UX "sees" an HP-UX system disk correctly installed that is with 3 partitions, from its own or not, it will create the /dev/disk or /dev/dsk corresponding to the partitions.

More : from the host you should also see the 3 partitions of your first VM.

Don't worry about that ;-)

Eric

[grahamswilson]

thanks both! As Duncan suggested, I simply assigned the complete disk resource to a newly created VM guest and it seems fine...

Having said that, the interesting thing is is that I am _not_ seeing the other partitions appear at the host level on my very first VM guest disk resource like you guys seem to be.

Whatever I do, (unpresent and represent the LUN etc.), the host only ever seems to see the single original LUN and not the partitions within it (that the guest does).

Here is the ioscan output :-

Class I H/W Path Driver S/W State H/W Type Description
===================================================================
disk 1 64000/0xfa00/0x0 esdisk CLAIMED DEVICE HP IR Volume
/dev/disk/disk1 /dev/rdisk/disk1
/dev/disk/disk1_p1 /dev/rdisk/disk1_p1
/dev/disk/disk1_p2 /dev/rdisk/disk1_p2
/dev/disk/disk1_p3 /dev/rdisk/disk1_p3
disk 10 64000/0xfa00/0x5 esdisk CLAIMED DEVICE HP HSV210
/dev/disk/disk10 /dev/rdisk/disk10
disk 28 64000/0xfa00/0x7 esdisk CLAIMED DEVICE HP HSV210
/dev/disk/disk28 /dev/rdisk/disk28
/dev/disk/disk28_p1 /dev/rdisk/disk28_p1
/dev/disk/disk28_p2 /dev/rdisk/disk28_p2
/dev/disk/disk28_p3 /dev/rdisk/disk28_p3

disk10 was the original LUN created on the SAN which was assigned as a disk resource to the first guest...with only 1 partition (even though the guest is now built)...

disk28 is a snapclone of the original LAN and then presented back to the host...with the regular boot disk multiple partitions...

I'll carry on playing (so I'll leave the thread open for now), as now I'm just intrigued why you see the multiple partitions even on your first guest...

I dont want to be the odd one out :)

[Eric SAUBIGNAC]

Try "insf -e" ... but I wonder, because it should have be done before, after presenting the snapcloned vDisk to the VM Host ... :-(

[Duncan Edmonstone]

Graham,

Possibly its because the original disk (disk10) went into the VM device database *before* the slices were created? Maybe the OS ignores disks which are already in the device database?

From an academic point of view, now these devices *are* in the device database (as you've created a VM guest with them as boot disks), it would be interesting to see what would happen if your rmsf'd the _pX DSFs and then rebooted the VM host - I wonder if they'd get re-created?

Just guessing...

HTH

Duncan

[grahamswilson]

thanks Eric - I had actually tried that (`insf -e etc.`), but that didn't do anything...

thanks Duncan - I also wondered if it may have something to do with the fact that the first disk went into the VM device database _before_, whereas the snapclone didn't...and that does seem like it could be a valid reason...

I couldn't resist working on the dsf's...I'll carry on playing around, but I did remove all the "extra" dsf's at the host level (both the agile and legacy equivalents for the diskXX_p?? devices) for all those extra partitions...and sure enough, they did NOT get recreated accross a reboot - and of course, the guest that disk was assigned to still seems fine...i.e. at the host, now I see :-

disk 10 64000/0xfa00/0x5 esdisk CLAIMED DEVICE HP HSV210
/dev/disk/disk10 /dev/rdisk/disk10
disk 28 64000/0xfa00/0x7 esdisk CLAIMED DEVICE HP HSV210
/dev/disk/disk28 /dev/rdisk/disk28

But I'm still intrigued though how both of you seemed to manage the "snapshot"/multiple partition type behavior on your first VM guests...weird?! Surely you must have also assigned the disk resource to the guest first so it was in the VM device database...?

[Eric SAUBIGNAC]

How did you removed dsf for partitions ? rmsf or just rm ? In fact I am far to be an expert with the new 11.31 io stack :-( May be you must do complementary action so that insf re-create partition dsf file, regardless wether or not HP VM is installed. Or maybe "insf -e" is no more sufficient ?

If the assertion that HP VM database involves how HP-UX handles dsf files, may be you could try to delete one VM, then test "insf -e". If you delete the VM, before keep in a corner the file "/var/opt/hpvm/guests//nvram". It contains EFI and its configuration. When you will re-create the VM after the test, copy back the file or you will have to create again the boot entry in EFI.


Eric

[grahamswilson]

...hmmm...

After my testing yesterday, I had actually deleted the snapclone and associated dsf's (with rmsf) and had tried `insf` (as per Eric's original suggestion) to see if I could reproduce the additional dsf's on the original LUN...with no luck.

After your latest post Eric, I did `insf -e` again and the dsf's I deleted earlier _have_ been recreated now on the snapclone (they weren't during a reboot)...AND even for the original disk!!

So I am now in a consistent state, like you both, with the extra DSF's for each guest.

I wonder if this is why, coincidently, you both had these extra dsf's already - i.e. at some point you had indeed run an `insf -e`...

I'm still a little confused why these additional dsf's weren't recreated yesterday when I was playing though - I need to re-read my notes I was taking to keep track of what I was doing...

I guess with the new I/O stack, it's doing something that isn't quite `insf -e` when it does it's automatic discovery, otherwise it would have created the new dsf's for the original LUN when it discovered the new LUN...but I suspect it only acts on newly discovered devices which may explain that.

I have another IVM host (same versions etc.) which has 6 guests on it - and as I've never done an `insf -e` on it - never need to these days - and I've not used snapclones either, it only has the diskXX dsf's and not the additional ones... I'm sure if I did the `insf -e` on that host now, I'd get a load more...so I wont. :)

So my understand of things is "clearer" now, or getting clearer at least. The new i/o stack, device/agile namings and IVM v4 are certainly something to keep things interesting!

[grahamswilson]

Closing thread...