- This topic has 19 replies, 8 voices, and was last updated 14 years, 2 months ago by
.
-
Topic
-
-
Replies
-
-
-
-
-
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=prodFEATURE cl-intfc-master hcilicmgrd 5.6 permanent uncounted D69E4FF6D144
HOSTID=c91b1d4c ck=110 category=prodFEATURE cl-mm-master hcilicmgrd 5.6 permanent uncounted D34CA05D8D7D
HOSTID=c91b1d4c ck=85 category=prodFEATURE cl-aom-odbc-mw hcilicmgrd 5.6 permanent uncounted C78BA3661BB4
HOSTID=c91b1d4c ck=37 category=prodFEATURE cl-aom-odbc-tcl hcilicmgrd 5.6 permanent uncounted 50C968322303
HOSTID=c91b1d4c ck=5 category=prodFEATURE cl-aom-ssl hcilicmgrd 5.6 permanent uncounted 0DE81936A521
HOSTID=c91b1d4c ck=209 category=prodFEATURE 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=prodFEATURE cl-intfc-master hcilicmgrd 5.6 permanent uncounted 6DF29DB1E465
HOSTID=c91b4d4c ck=142 category=prodFEATURE cl-mm-master hcilicmgrd 5.6 permanent uncounted F15B1C3A150B
HOSTID=c91b4d4c ck=181 category=prodFEATURE cl-aom-odbc-mw hcilicmgrd 5.6 permanent uncounted 950FABADE119
HOSTID=c91b4d4c ck=197 category=prodFEATURE cl-aom-odbc-tcl hcilicmgrd 5.6 permanent uncounted 7ED0189FB7FD
HOSTID=c91b4d4c ck=229 category=prodFEATURE cl-aom-ssl hcilicmgrd 5.6 permanent uncounted 4DC128D34BF8
HOSTID=c91b4d4c ck=49 category=prodFEATURE cl-aom-ftps hcilicmgrd 5.6 permanent uncounted 1471559C1079
HOSTID=c91b4d4c ck=222 category=prodHowever, 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-ftpsRuss Ross
RussRoss318@gmail.com -
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.
-
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 -
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:86inet 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)
…
-
-
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,
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] -
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 1on 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 65536on 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 1We 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 -
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:
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, 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-T1on 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-T6on 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-T6Russ Ross
RussRoss318@gmail.com -
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
