Integrity Virtual Machines

[Tim Hempstead]

We are looking at the moment at the possibilities with implementing Integrity Virtual Machines on our estate. Generally it seems to make sense but we do have one question though at the moment ...

If we have say a C-class blade running several VMs which are housed entirely on the SAN. If we then had a hardware issue which took out that Blade, could we then rezone that SAN disk to another C-Class Blade and then bring up the VM's on there thus restoring the system availability before the hardware is repaired?

Is this possible and how easy would it be to "import" the VM on the replacement box from an Integrity VM point of view?

[Torsten. · Accepted solution]

Hi,

the Integrity Virtual Machines product needs of course an Integrity server to run (in your case the BL860c).

The best idea would be to integrate the virtual machine in MC/Serviceguard, so if a host system fails, the virtual machine will start on another configured node automatically.

But also if you "manually move" the vm (config) and re-zone, re-present ... it should be possible to run (but it will likely take more time).

[Gordon Crone]

Also, with support for BL860c blades 'any day now', you could use the Virtual Connect Fiber modules, and you would not have to rezone anything, just re-map the fiber to another blade and power up.

[Phillip Thayer]

Provided that you are booting from the SAN. Then it is simply a matter of, I believe, three mouse clicks and power up the blade to get right back to where you were. You would have downtime for the time it would take to do the reboot.

If you want automated failover you will need to use MCSG to accomplish the failover in seconds rather than minutes.

Phil

[Torsten.]

It depends on some other points too.
How did you configure the backing storage?
(disk/lvol/file). You need to adjust this to the other blade. Additionally you need to "import" the HPVM config.

[Tim Hempstead]

We've rulled out using ServiceGuard to fail VM's over on cost grounds, (the SLA on these systems means that we have a few hours to get things running instead of a few minutes so justifying it wasn't possible (I would have like to have done it as it would be new and interesting but I don't control the budget!).

Regarding Torstens comment about the backing storage, we're still in the planning stage at the moment so that hasn't been finalised. I'm guessing that using files as the backing storage would be the least recommended as it would look like it has the most overhead involved. I would imagine that we would need to import the disks into the vmhost, (vgimport if using lvols), and then when they were visible import the VM configuration. Or if the disk storage is being used then if devices have changed then vgimports may need to be run on the VM itself to pick it back up?

(We will be writing system configurations out to Ignite servers which are outside the blade environment so should have access to the info we need).

[Torsten.]

Consider this:

IF you are running serviceguard on the host, you need to configure the backing storage as LVM volumes. If you are running serviguard on the guest, you need to present the backing store as plain disks. In this case you need a multipath solution (e.g. autopath) running on the host.
See the manual for more information.