VMotioning Cloverleaf on Linux on VMWare

We are running on VMWare ESX, and while I have not had the guts to VMotion while the engine is running, we have moved the machine (shutdown) between the ESX servers.  There’s no reason to doubt that machine would move properly, but I don’t want to poke it with a stick.

I’m curious to know if you guys are saying that the ouptut from running hcihostid will be the same on 2 different virtual servers each running on a different physical box after doing a VMotion with VMWare ESX.

For example, lets say that you run hcihostid on the currnet active virtual server running on physical box 1 and get

c91b1d4c

then you fail-over and run hcihostid on the fail-over virtual server running on physical box 2 that is now active does it also display

c91b1d4c

In other words, does VMWare ESX VMotion cause the hcihostid to fail-over if the fail-over virtual server is on a different physical box?

Under my OS (AIX using HACMP) only my LPARs (virtual servers) on the same physical box have the same hcihostid and failing over to a partition on the same physical box would not be acceptable fail-over at my place of business.

Therefore, I have to have an entry in the cloverleaf license file for both hcihostids associated with each physical box.

However, a test environment and prod environment running on differnet LPARs (virtual servers) on the same box can have the same idential Cloverleaf license file and work just fine.

Therfore, I’m intrigiued by what you might be saying expecially if the VMWare ESX VMotion litterally causes the physical identity of the box to fail-over transparently at the hcihostid level.

I’m suspect my imagination is running a bit wild but never hurts to ask.

Wondering if anyone’s had success with VMotioning Cloverleaf on Windows.  Thanks in advance for any feedback!  We’re looking for low cost options to Cloverleaf HA.

I believe that “it just works”.  We did a memory upgrade on our servers here a while back, and we shut down all the unnecessary VMs and VMotioned the ones that had to stay up (Cloverleaf).  We put in memory, booted the box, and failed the VMs over the the newly upgraded box while we upgraded the other one.  I’ve also seen our Cloverleaf VM automagically move to the other server based on DRS considerations (CPU, Memory balance…)

Our experience with using Cloverleaf on Red Hat, running on a VM have been very positive.

Terry:

I’m curious if you vmotion to another physical box and then stop/start a cloverleaf process will it start again?

I’m aware that vmotion will work for Cloverleaf as long as nothing is cycled during the maintance window and then you vmotion back to your licensed physical server.

I’ve heard from others that could not stop and start any cloverleaf processes if they had vmotioned to another physical box and I wanted to hear if you had actually tried to cycle any cloverleaf processes while vmotioned to another physical box?

Yes, we have run our RedHat/Cloverleaf 5.6 VM on both our physical servers with no problems.

When Cloverleaf goes for a HostID, it looks at certain “physical parameters” to determine what that HostID is.  Cloverleaf, or really any other end-user software cannot really “see” the physical hardware.  It only “sees” the virtual presentation that VMWare (Specifically the .vmx file) makes to the OS.  That machine is really encapsulated within it’s virtual machine container (is it live or is it Memorex?) and can only see outside it’s own VM by using APIs presented by VMWare at the BIOS level, or VMWare Tools at the OS level.

As far as I know, they have not yet included any “outside” physical parameters in the HostID calculation.

It really HAS to work that way in order for the idea of VMs to work at all.  I would even go so far as to consider it a “bug” if Cloverleaf were modified to intentionally look outside the Virtual Container to change the HostID.

I’m trying to be a bit vague as there are those who have a bit less integrity about these things than we do. (Shock!)  😉