How to switch physical volume on VM Guest

[Tim Medford]

I have a LUN presented to an integrity VM as a vdisk, so in other words no LVM setup on the VMHost, it is presented in raw format.

I do not have securepath installed on the VMhost and do not want to present LVM volumes or files for performance reasons.

Let's suppose the disk I present to the VM goes through HBA1 on the VMHost and ControllerA on the EVA6000. So the path might be something like /dev/dsk/c4tod1. There's some alternate paths of course through controllerB and HBA2, but you can only present 1 path to the VM Guest.

On the VM I then have a VG created which uses that disk. I'm trying to figure out a strategy for recovering from either HBA1 failing on the vmhost, or ControllerA dying on the EVA side.

PVLinks are not supported inside the VM Guest so assuming I want to stay with vdisks and assuming I don't have securepath on VMhost, how would I recover from either scenario.

I was thinking I could present to other physical path to the VMGuest (c6t0d1) but then is there some kind of vgchange I could do on the volume group to switch out the current pv and substitute in the new one?

I guess I'm trying to replicate the process that PVLinks give us for free.

Thanks in advance for any ideas.

[Torsten.]

Hi Tim,

"I guess I'm trying to replicate the process that PVLinks give us for free."

Yes, more or less.

As long as the host is not supported with 11.31 and you don't want to pay for multipathing software, you need to look for alternative ways.

If your path fails, the HPVM guest will crash. You can delete the path from the guest config and add another. Doing this, the device file inside the guest will be the same again and you can boot, I guess.

I set up some guests using LVM LUNs on the host - the performance is OK. Doing this I have the advantage of pvlinks. Of course not all guests are using the same HBA and path.

Did you try to compare the performance?

In your situation, using LVM on the host may be the most safe way (without multipathing software).

[Torsten.]

This is from the manual:

"Each release of the Integrity VM storage subsystem strives to improve performance."

I just noticed version 3 is out.

See

http://docs.hp.com/en/new.html#HP%20Integrity%20Virtual%20Machines

and

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=integrity_vm

[Tim Medford]

Thanks for the input.

I have compared performance, and the difference is substantial. I ran a test about 10 times and compared the averages.

Copying a filesystem with lots of subdirectories and smaller files the performance is about the same, although slightly slower with lvdisk.

Copying 1 large tar file took 50% longer with lvdisk as compared to vdisk. Seems like it might be a blocking factor issue possibly, but not sure.

I will look into v3 of the IntegrityVM software, thanks.

In the meantime, how would you go about switching over the path? I know on the VMHost it would be a simple matter of un-presenting the current c4t0d1 and then presenting the c6t0d1 path instead. But then on the VMGuest, how to handle it? I was thinking I'd need to vgexport, change the physical path and then vgimport back on the vmGuest?

[Torsten.]

I guess, if your device file inside the guest is c0t0d0 and you remove the vdisk from the config and add another, the device will remain the same. So no modification is needed for the guest itself.

performance vs. availability

As mentioned above, your guest will crash if the path fails.

[Tim Nelson]

One thing that I found interesting while testing this as I am interested in a solution as well.

When I attempted to present the other path to the VMGuest at a different HW address the hpvmmodify failed stating that it was a duplicate backing store. The VMHost seems to know that it is a multipathed device.

Maybe this is obvious maybe not.

[Torsten.]

obviously the host is checking the device before accessing it (or destroy something) while changing the config.

Look at this example from another thread:

"WARNING: The disk at: 0/0/0/0.0x0.0x0 (HP_Virtual_Disk) appears to contain a file system and boot area. Continuing the installation will destroy any existing data on this disk."

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1128944

[Tim Medford]

Hi Tim,

Did you try unpresenting the original path before presenting the alternate?

Delete original:
hpvmmodify -P guestname -d disk:scsi::disk:/dev/rdsk/c4t0d1

Present alternate:
hpvmmodify -P guestname -a disk:scsi::disk:/dev/rdsk/c6t0d1

[Tim Nelson]

Did not try that yet.. Have active Oracle test instance on the disk.

I will try when I get a chance with a fresh disk as I would think it would be possible to swap the underlying disk..

I believe the VMGuest will have to be shutdown in order to remove the 1st path and replace with the alternate.

[Tim Medford]

Hi Tim,

I did some more experimentation with this. It looks like the hardware path on the VM guest does not change when the alternate path from the VMHost is presented.

I have a VM Guest called voyager with the root vg installed on Vdisk. The vdisk was presented as c4t0d1 from VMhost. On the VMGuest the hardware path is

disk 1 0/0/0/0.1.0 sdisk CLAIMED DEVICE HP Virtual Disk
/dev/dsk/c0t1d0 /dev/rdsk/c0t1d0
/dev/dsk/c0t1d0s1 /dev/rdsk/c0t1d0s1
/dev/dsk/c0t1d0s2 /dev/rdsk/c0t1d0s2
/dev/dsk/c0t1d0s3 /dev/rdsk/c0t1d0s3

To test what happens when the controller dies I unpresented the root disk while the VMGuest was up and running.

hpvmmodify -P voyager -d disk:scsi::disk:/dev/rdsk/c4t0d1

The VM crashed as expected. Although when I ran hpvmstatus it reported it as On(os). So I the issued an hpvmstop. I then presented the alternate path to the root disk.

hpvmmodify -P voyager -a disk:scsi::disk:/dev/rdsk/c6t0d1

I restarted the VM Guest and everything came up fine. It did run fsck and sanity checks on all the filesystems, but worked ok. The hardware path and device files for the root VG on the VMGuest looks exactly the same as before.

This is no guarantee that it will always work, I suppose the root VG could have been corrupted had it been in the middle of writing something. In that case I'd still present the alternate path but then perform whatever recovery was necessary.

Hope this is helpful,
Tim