VMware and Cloverleaf

Don, do a search on “vmware” and you’ll find a couple of real good discussions on the topic. We’re on RedHat and VMWare and we love it.

We use Cloverleaf on RedHat on VMWare and are loving it.

A few weeks ago, we upgraded the memory on our VMWare boxen and were able to bounce our Cloverleaf instance from one physical server to the other without any heartburn.

We have VmWare and running Cloverleaf on it sounds like a good idea. One question though. How do you ensure the host Id (for licenising)remains consistent if you reconfigure Cloverleaf to run as a different instance?

Our approach to getting the license.dat file to work across nodes with different HOSTIDs (note HOSTID != hostname), is to have an entry specific to each HOSTID in the same license.dat file.

On our AIX platform as long as the virtual LPARs/servers/hostnames are done on the same physical box the HOSTID required by the license key will be the same.

But when we go to a differnet physical box like a HACMP fail-over configuration then the HOSTID which is tied to the physical hardware will be differnet.

In other words, hostnames don’t play a role in the license.dat file that I can tell but the physical HOSTID of the box is what it currently uses in cloverleaf 5.6 and earlier on AIX servers.

That means as long as all your virtual machines/hostnames run on the same physical box they can all use the same idnetical license.dat file successfully from what I’ve experienced.

You might be askign the question, “Then what would prevent you from buying a license for one cloverleaf server and running cloverleaf on multiple virtual servers on the same physical box for the cost of a single license?”

It seems to me nothing other than honesty would prevent it with the current design which predates the growing use of virtual machines.

When the virtual machines reside on different physical hardware is when I’ve had to make an entry in the license.dat file for each physical server.

Here is an example of one of our license.dat files that could be run on 2 different physical fail-over nodes in one of our HACMP clusters either mdahub8 or mdahub9:

However, it is still nice to be able to test if a certain license.dat file will work ahead of time.

I was able to test my license.dat file ahead of time via a temporary NFS mount of my active cloverlef server onto the idle virtual LPAR and use hcilictest command as follows:

.

That means as long as all your virtual machines/hostnames run on the same physical box they can all use the same idnetical license.dat file successfully from what I’ve experienced.

I think the license is tied to (among other things) the MAC address of the host’s NIC. Even though VMware allows static, user-defined, virtual MAC addresses, I don’t think one could run a second virtual machine on the same subnet with the same virtual MAC address.

I’m a virtual noob so I might be mistaken.

I have not observed that the MAC address impacts the cloverleaf license.

For example, we have one physical box with 2 LPARs (statically allocated virtual machines) each with its own set of 3 NICs.

One LPAR is our PROD server and the other is our TEST server.

I use the same identical license file entries for both the PROD and TEST server.

I don’t believe this would work if MAC address was a consideration in the license file at least this seems to be my observation for our AIX environment.

Looking more closely, it appears there’s a one to one correlation of the HOSTID (which is used to create license key) and the MAC address.

#>hcihostid

0002a54fb986

#>cat license.dat

FEATURE cl-pkg-cl hcilicmgrd 5.6 permanent uncounted 0720833E051B

       HOSTID=0002a54fb986 ck=21 category=testdev

…

#>ifconfig -a

bond0     Link encap:Ethernet  HWaddr 00:02:A5:4F:B9:86  

         inet addr:129.176.186.20  Bcast:129.176.187.255  Mask:255.255.252.0

         inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link

         UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

         RX packets:796745279 errors:0 dropped:0 overruns:0 frame:0

         TX packets:207375339 errors:2609357 dropped:0 overruns:0 carrier:2609357

         collisions:4004625 txqueuelen:0

         RX bytes:3305088748 (3.0 GiB)  TX bytes:2337236831 (2.1 GiB)

…

The license is tied to the MAC address of the box’s primary NIC. Regardless of the number of VMs running on the box, the physical box itself only has one primary NIC.

Bob: hcihostid returns that MAC address.

Chris

Thanks Bob and Chris for educating me on the realationship with the MAC address and how it relates to the physical box.

This would explain why it appears to me the license key is tied to the physical box when it is in reality tied to the primary MAC address of the physical box.

Does that mean if our primary NIC fails and we end up running on a standby NIC and replace the primary NIC thus changing the MAC address, I can expect Cloverleaf license file to no longer work as is?

Yes.

Chris,

There are virtual MAC addresses in the VMware world. The virtual MAC address is what the Cloverleaf license verification logic should see.

Russ,

If you change the MAC address on the secondary NIC to be that of the failed primary NIC, the original Cloverleaf license should work.

As root:

[/code]

Since my question raises a concern of a single point of failure in our HACMP environment I got with another system admin to discuss and he tells me that under AIX the license is tied to the serial number and not the MAC address.

He said that might not be the case running RedHat or VMware.

Here are the facts he shared with me to make me once again think the license is tied not to our primary MAC address.

Let me provide some output from the following 3 commands on each of our 3 LPARs on one physical box:

hcihostid

uname -a

ifconfig -a

The outout of ( hcihostid ) on all 3 LPRARs (mdahub4, mdahub6, mdahub8) are the same:

c91b1d4c

The output of ( uname -a ) on all 3 LPARs matches the hcihostid:

on mdahub4 = AIX mdahub4 3 5 00C91B1D4C00

on mdahub6 = AIX mdahub6 2 5 00C91B1D4C00

on mdahub8 = AIX mdahub4 3 5 00C91B1D4C00

The output of ( ifconfig -a ) doesn’t match hcihostid that I can see:

on mdahub4 output of ( ifconfig -a )

on mdahub6 output of ( ifconfig -a )

on mdahub8 output of ( ifconfig -a )

We have a highly available setup and our system admin reminds me he thinks we tested failing over from the primary NIC to a secondary near and thinks he remembers failing over for real once.

I remember a NIC fail-over for real once but it was to the secondary physical box with 3 more different LPARS (mdahub5, mdahub7, mdahub9) when the network team essentially deleted our entire network with a screw up, so after it failed over there was still no network to connect to.

Our system admin was wondering if either of you ( Bob or Chris ) are running on something other than AIX like RedHat because he thinks the output I provided doesn’t suggest the license is using the MAC address and thinks it is using the serial number of the physical box.

I would be curious to see a comparision of your hcihostid and serial number to see if thye match.

I’m starting to wonder if the license key might be serial number on AIX and primary MAC address on something like you guys are running.

If you can provide the output from ( hcihostid ) compared to ( uname -a ) or whatever command shows your serial number of the physical box I would appreciate seeing if they match or not.

Bob wrote

We do use a virtual service address IP which fails over form NIC to NIC to NIC to machine to NIC, etc.

I was reminded this was tested and apparently occured one time and worked as designed.

On our older setup the MAC address is differnet on each NIC and the NIC fail-over we think did work but we are a bit fuzzy and unsure.

On our newer setup we use ether channels which come to find out assigns one MAC address to all the NICs in the pool, so yet another reason I’ve come to like ether channel much better.

A long time ago I had also posted if anyone knew if ether channel would work for SNA and the anser is – yes we have it working just fine.

Russ,

I don’t think there’s a host serial number in the Intel world.

I’d be curious what

shows on your AIX host.

Bob:

Here are the NIC fail-over related commands I do for the old setup

Here are the NIC fail-over related commands I do for the new ether channel setup

As you can see I did not take specify anything about the MAC address which from what I’ve been told today is done majically for me with the new ethernet setup we are using and jsut about completely upgraded to.

Russ,

Thanks for all the info.

AIx’s HACMP design is different than VMware’s HA.

I’m still curious about how the hcihostid is derived on AIX.

–Bob

On AIX 5.3 running Cloverleaf 5.5..

hcihostid returns…

b2314d6

uname -m returns…

000B2314D600

lscfg -vl ent0 returns…

Bob, here is my ouput from running

lscfg -vl ent0

on the following 3 LPARs

mdahub4

on mdahub6

on mdahub8

Todd, we have our most current LPARs running at Cloverleaf 5.6 and AIX 5.3 and it seems to still be tied to the serial number of the physical box and not MAC address.