VMware and Cloverleaf

[Don Anderson]

I would like to get some opinions and input on using VMware to load Cloverleaf

Good and Bad. ❓

I have 1 white paper from the Florida Hospital

Topic

[Max Drown (Infor)]

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.

-- Max Drown (Infor)

[Terry Kellum]

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.

[David Harrison]

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?

[Russ Ross]

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:

Code:

#————————-
# license keys for mdahub8
#————————-

FEATURE cl-pkg-cl hcilicmgrd 5.6 permanent uncounted D5C2BD2F26AA
       HOSTID=c91b1d4c ck=168 category=prod

FEATURE cl-intfc-master hcilicmgrd 5.6 permanent uncounted D69E4FF6D144
       HOSTID=c91b1d4c ck=110 category=prod

FEATURE cl-mm-master hcilicmgrd 5.6 permanent uncounted D34CA05D8D7D
       HOSTID=c91b1d4c ck=85 category=prod

FEATURE cl-aom-odbc-mw hcilicmgrd 5.6 permanent uncounted C78BA3661BB4
       HOSTID=c91b1d4c ck=37 category=prod

FEATURE cl-aom-odbc-tcl hcilicmgrd 5.6 permanent uncounted 50C968322303
       HOSTID=c91b1d4c ck=5 category=prod

FEATURE cl-aom-ssl hcilicmgrd 5.6 permanent uncounted 0DE81936A521
       HOSTID=c91b1d4c ck=209 category=prod

FEATURE cl-aom-ftps hcilicmgrd 5.6 permanent uncounted B5B908FA1852
       HOSTID=c91b1d4c ck=62 category=prod

#————————-
# license keys for mdahub9
#————————-

FEATURE cl-pkg-cl hcilicmgrd 5.6 permanent uncounted CC70A23CD355
       HOSTID=c91b4d4c ck=72 category=prod

FEATURE cl-intfc-master hcilicmgrd 5.6 permanent uncounted 6DF29DB1E465
       HOSTID=c91b4d4c ck=142 category=prod

FEATURE cl-mm-master hcilicmgrd 5.6 permanent uncounted F15B1C3A150B
       HOSTID=c91b4d4c ck=181 category=prod

FEATURE cl-aom-odbc-mw hcilicmgrd 5.6 permanent uncounted 950FABADE119
       HOSTID=c91b4d4c ck=197 category=prod

FEATURE cl-aom-odbc-tcl hcilicmgrd 5.6 permanent uncounted 7ED0189FB7FD
       HOSTID=c91b4d4c ck=229 category=prod

FEATURE cl-aom-ssl hcilicmgrd 5.6 permanent uncounted 4DC128D34BF8
       HOSTID=c91b4d4c ck=49 category=prod

FEATURE cl-aom-ftps hcilicmgrd 5.6 permanent uncounted 1471559C1079
       HOSTID=c91b4d4c ck=222 category=prod

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:

Code:

hcilictest cl-intfc-master
hcilictest cl-mm-master
hcilictest cl-aom-odbc-mw
hcilictest cl-aom-odbc-tcl
hcilictest cl-aom-odbc-tcl
hcilictest cl-aom-ssl
hcilictest cl-aom-ftps

Russ Ross
RussRoss318@gmail.com

[Bob Moriarty]

Russ Ross wrote:

.

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.

[Russ Ross]

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.

Russ Ross
RussRoss318@gmail.com

[Bob Moriarty]

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)

…

[Chris Williams]

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

[Russ Ross]

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?

Russ Ross
RussRoss318@gmail.com

[Chris Williams]

Yes.

[Bob Moriarty]

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:

# ifconfig eth0 down
# ifconfig eth0 hw ether 00:80:48:BA:d1:30    (e.g.)
# ifconfig eth0 up

[/code]

[Russ Ross]

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 )

Code:

en2: flags=5e080863,c0
       inet 10.111.87.147 netmask 0xffffff80 broadcast 10.111.87.255
        tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
lo0: flags=e08084b
       inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
       inet6 ::1/0
        tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

on mdahub6 output of ( ifconfig -a )

Code:

en2: flags=5e080863,c0
       inet 10.111.87.141 netmask 0xffffff80 broadcast 10.111.87.255
        tcp_sendspace 131072 tcp_recvspace 65536
en0: flags=5e080863,c0
       inet 10.10.15.180 netmask 0xffffff80 broadcast 10.10.15.255
       inet 10.111.87.146 netmask 0xffffff80 broadcast 10.111.87.255
        tcp_sendspace 131072 tcp_recvspace 65536
en1: flags=5e080863,c0
       inet 10.10.15.80 netmask 0xffffff80 broadcast 10.10.15.127
        tcp_sendspace 131072 tcp_recvspace 65536
lo0: flags=e08084b
       inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
       inet6 ::1/0
        tcp_sendspace 65536 tcp_recvspace 65536

on mdahub8 output of ( ifconfig -a )

Code:

en2: flags=5e080863,c0
       inet 10.10.15.35 netmask 0xffffff80 broadcast 10.10.15.127
       inet 10.111.87.148 netmask 0xffffff80 broadcast 10.111.87.255
       inet 10.111.87.143 netmask 0xffffff80 broadcast 10.111.87.255
        tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
lo0: flags=e08084b
       inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
       inet6 ::1/0
        tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

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.

Russ Ross
RussRoss318@gmail.com

[Russ Ross]

Bob wrote

Code:

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.

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 Ross
RussRoss318@gmail.com

[Bob Moriarty]

Russ,

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

Code:

uname -a
Linux clovertestl.mayo.edu 2.6.9-89.0.9.ELsmp #1 SMP Wed Aug 19 08:07:15 EDT 2009 i686 i686 i386 GNU/Linux

I’d be curious what

Code:

lscfg -vl ent0

shows on your AIX host.

[Russ Ross]

Bob:

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

Code:

#—————————————————————————-
# down & detach en2 which has the persitant IP and gateway on it
# then add gateway which will seek out and attach itself to the service address NIC
#
# this is so that all inbound and outbound trafic will failover transparently
#—————————————————————————-

ifconfig en2 down detach; route add 0 10.111.87.129

#——————————————————————
# then enable the NIC with the persistant IP
# (note: If you move this above the SNA stuff above,
#        then SNA will use en2 persistant NIC
#        which is outside of HACMP.  This might be desirable
#        if network traffic on the service address NIC (en0 or en1)
#        becomes a bottle neck)
#——————————————————————

ifconfig en2 inet 10.111.87.141 up
chdev -l ‘en2′ -a state=’up’ -a broadcast=’10.111.87.255′

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

Code:

#——————————————————————————————-
# remove the persitent address ether channel alias from en2 to assure all outbound traffic
# will use the service address ether channel alias on en2 as the default address
#
# Note:
# – this is so that all inbound and outbound trafic will failover transparently
# – the hostname is the name of the persistent address
#   because it is no longer necessary to set the hostname to the name of the service address
#——————————————————————————————-

ifconfig en2 $HACMP_ORIG_HOSTNAME -alias

#———————————————————————————————————
# add back the ehter channel alias for the persistent address on en2
# now that the ether channel alias for the service address is the default address for all outbound traffic
#———————————————————————————————————

ifconfig en2 $HACMP_ORIG_HOSTNAME netmask 255.255.255.128 alias

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 Ross
RussRoss318@gmail.com

[Bob Moriarty]

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

[Todd Lundstedt]

On AIX 5.3 running Cloverleaf 5.5..

hcihostid returns…

b2314d6

uname -m returns…

000B2314D600

lscfg -vl ent0 returns…

[Russ Ross]

Bob, here is my ouput from running

lscfg -vl ent0

on the following 3 LPARs

mdahub4

Code:

 ent0             U7879.001.DQD07MV-P1-C5-T1  10/100/1000 Base-TX PCI-X Adapter (14106902)

     10/100/1000 Base-TX PCI-X Adapter:
       Part Number……………..00P6130
       FRU Number………………00P6130
       EC Level………………..H12818
       Manufacture ID…………..YL1021
       Network Address………….000255D3DDFD
       ROM Level.(alterable)…….GOL021
       Hardware Location Code……U7879.001.DQD07MV-P1-C5-T1

on mdahub6

Code:

 ent0             U7879.001.DQD07MV-P1-T6  2-Port 10/100/1000 Base-TX PCI-X Adapter (14108902)

     2-Port 10/100/1000 Base-TX PCI-X Adapter:
       Network Address………….00096BDD4490
       ROM Level.(alterable)…….DV0210
       Device Specific.(YL)……..U7879.001.DQD07MV-P1-T6

on mdahub8

Code:

 ent0             U7879.001.DQD0DD9-P1-T6  2-Port 10/100/1000 Base-TX PCI-X Adapter (14108902)

     2-Port 10/100/1000 Base-TX PCI-X Adapter:
       Network Address………….00096BDD2D72
       ROM Level.(alterable)…….DV0210
       Hardware Location Code……U7879.001.DQD0DD9-P1-T6

Russ Ross
RussRoss318@gmail.com

[Russ Ross]

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.

Russ Ross
RussRoss318@gmail.com

[Author]

Replies