How migrate VM in case of server crash

[Vishu]

Hi Gurus,

I have a VM guest, which i used to migrate online to another VM host in case of any maintenance on first VM host and it is successful till now.

My question is - What if my first VM host crashes, how would i migrate that VM guest to second VM host? i mean from where i would issue that hpvmmigrate command?

My VM guest is created with npiv adapter with storage directly assigned to VM guest, not through the VM host.

One thing is to configure the VMs as a serviceguard package, but is there any other way without the serviceguard??

thanks

This thread has been moved from HP-UX>System Administration to HP-UX > virtualization

[Dennis Handly]

>What if my first VM host crashes, how would i migrate that VM guest to second VM host?

If your host crashes, you are no longer "online".

>One thing is to configure the VMs as a Serviceguard package

That's what I was thinking.

[Vishu]

Hi Dennis,

Thanks for your reply. i agree with you. But i dont have serviceguard in my environment here. Is there any other possibility to run my VM guest on the other VM host in case of first VM host crashes, like we do vm migration. Please suggest.

[Dave Olker]

Assuming you have successfully migrated the VM between hosts previously and the VM guest configuration has not changed, it is technically possible to start the VM on the other host if the primary host crashes.  However, it's a dangerous procedure and HP strongly discourages this because it can lead to a case where the same VM is attempting to boot/run on multiple VM hosts.  That can cause data corruption.  So again, possible but definitely not recommended - especially with VM guests configured for Auto Boot and no Serviceguard in the picture.

Regards,

Dave

[Vishu]

Hi Dave,

I saw a hope in your reply. Can you please share that procedure with me? I would definitely take precautions while using that procedure, beacuase that is the only thing i guess can help us out in case of server crash.

Appreciate your help.

Thanks

[Dave Olker · Accepted solution]

Yes, it is possible to start the VM on another host as long as it has an up-to-date copy of the guest configuration. This would typically be the case if you've migrated the guest between servers and haven't modified the guest configuration since the last migration.

In my lab environment I have two VSPs (VM Hosts) - atcuxbl7 and atcuxbl8.  I create a VM on atcuxbl8 and migrate it to atcuxbl7.  If you look at the VM guest configuration on both servers via "hpvmstatus -V -P <guest>" in this state, atcuxbl8 will report the following information:

Runnable status : Not runnable
Not runnable set by : Migrate
Not runnable reason : vPar or VM has been migrated to VSP atcuxbl7.
Modify status : Not modify
Not modify set by : Migrate
Not modify reason : vPar or VM has been migrated to VSP atcuxbl7.
Visible status : Not visible
Not visible set by : Migrate
Not visible reason : vPar or VM has been migrated to VSP atcuxbl7.

Looking at the same output for the same VM on atcuxbl7 (where the VM guest is running):

Runnable status : Runnable
Modify status : Modify
Visible status : Visible

It is these fields that determine whether the guest can be run or not.  As proof of this, I stopped the VM guest on atcuxbl7 (to simulate a server crash) and then attempted to start the guest on atcuxbl8:

atcuxbl8(/) -> hpvmstart -p1
hpvmstart: vPar or VM had been disabled for the following reason: 'vPar or VM has been migrated to VSP atcuxbl7.'.
vPar/VM atcuxvm1 configuration problems:
Warning 1: vPar/VM 'atcuxvm1' is not runnable.
These problems may prevent the vPar or VM atcuxvm1 from starting.
hpvmstart: WARNING (atcuxvm1): vPar/VM 'atcuxvm1' is disabled.
hpvmstart: Unable to start vPar or VM 'atcuxvm1'.
hpvmstart: Unable to continue.

As expected the attempt to start the guest fails because the guest configuration states this VM is not in the right state to be considered runnable.  I can forcibly change those three settings shown above to the needed values with the hpvmmodify command:

atcuxbl8(/) -> hpvmmodify -P atcuxvm1 -x runnable_status=enabled -x modify_status=enabled -x visible_status=enabled

Now the guest is considered visible, modifiable and runnable.  I can now start the guest on atcuxbl8:

atcuxbl8(/) -> hpvmstart -p1
(C) Copyright 2000 - 2013 Hewlett-Packard Development Company, L.P.
Mapping vPar/VM memory: 8192MB
mapping low RAM (0-80000000, 2048MB)

...

Again, the danger is if atcuxbl7 comes back up and attempts to start the guest there could be......trouble.  Even the hpvmmodify man page contains the warning:

Note: HP does not recommend using -x
runnable_status, -x modify_status, or -x
visible_status except with extreme
caution. Integrity VM ensures that the VM
is runnable only on one VSP at a time.
Marking a VM runnable on more than one VSP
can lead to accidentally booting the VM on
more than one VSP.

If modify_status is disabled, the VM is
most likely running on another VSP. Any
modification made to this VM's
configuration will be lost when it is
migrated back to this VSP.

Good luck,

Dave