I think we are all familiar with the manual MAC address issue - some software depends on the MAC for licensing, and in VMware you need to stick to a certain range of Ethernet addresses if you want to be able to manually put in your own MAC address.
Somehow I think that should have been written in big, bold letters before I started virtualizing a couple of years ago. I'm pretty sure it wasn't mentioned in the class, either. I have several apps that generate their license based on a server's MAC. And yes, now I have to change virtual NICs on several VMs from either Flexible or E1000 to VMXNET2.
Currently running vSphere 4.1, ESX build 320092 across the board.
Since I didn't plan ahead far enough to manually put in those MAC addresses, now I have no choice but to find some way to keep them until the vendors can regen the licensences.
So, here's the procedure I'm using to keep the MAC address:
1) Write down the old MAC
2) Replace Flexible NIC with VMXNET2
3) Unregister the VM
4) Edit the .vmx file and replace the automatically assigned MAC address with the old MAC address
- this is how I get around the GUI
5) Re-register the VM with the host
6) Boot up
So far it has worked for me just fine on two test servers. The question is: Will this cause any problems down the road?
I am currently running a "vanilla" network setup - no distributed vSwitches. However I do plan on putting that in place later this year, and that's where I'm not sure it my little procedure will come up to surprise me at that point.
I would make the MAC change within the OS rather than manually in the vmx file. It is usually very easy to do within the OS. In Windows you can modify the NIC properties and add the MAC address.
I'd rather be able to use ANY mac address, rather then have to use the VMware ID. One thing Xen has over VMware...
I have a *really* old software that hasn't been virtualized yet because of the hassle going through and getting it re-licensed. Perfect candidate otherwise...just hate the idea of having to get a new license.
The spirit of the MAC address usage is that they manufacturer specific. In essence VMware is a manufacturer of virtual adapters and uses it's assigned block.
Sorry, guys, changing the MAC from inside the guest OS does not work for all apps. I've tried it, and one of the apps was smart enough to "sniff out" the MAC assigned by VMware. In addition to that 2 of the apps I'm working with are Linux based. Same thing there - you can change the MAC address with the ifconfig command but when I tried it, the app wouldn't acknowledge it.
My problem is not the fact that you can't assign just any old MAC - I'm quite alright using the VMware assigned MAC. I just need to be able to retain it when replacing the virtual NIC, such as in the example of going from a "Flexible" NIC to a VMXNET2 NIC.
Thus I created the procedure detailed above, where essentially I get around the vSphere GUI.
Now the question is - will that get me in any trouble down the road? Can I find my self in a situation where VMware suddenly says "Something's wrong with my MAC assignment table"?
In fact, does anyone know the algorithm that VMware uses for generating the last 3 bytes of the MAC address?
Well, I found the MAC generation algorithm in KB Article 219 (http://kb.vmware.com/kb/219). Apparenty it's also described in the ESX Configuration Guide, in Chapter 5. I guess it helps to RTFM.
And then there also KB 507 (http://kb.vmware.com/kb/507), which says not to change the line ethernet0.generatedAddress in the .vmx file.
In my case that is exactly what I've been doing - modifying the generatedAddress line and re-registering the VM. I guess I'll need to spend a day playing around to see if and how I can break my test VMs, and if the MAC will somehow change between VM power cycling.
I have done this many times in the OS and it normally works just fine. The network should see the replaced MAC address. What software is the original MAC in spite of it having been replaced?
One of the pieces of software that doesn't work is called Cloverleaf (Linux based). This is something you will find in Healthcare IT shops. Luckily for me, the software maker was quick to redo the licensing there. Another piece of Windows software is called Autonomy.
When you ask what the software is, I'm not sure what you're expecting to hear. These are programs that are pretty much specialized for specific industries. Some of them require multiple servers to host the different pieces.
There are times when changing the MAC from inside the guest simply doesn't cut the mustard.
Interesting to know about Cloverleaf. We run that here, but on IBM Power servers. Very curious to the size of your hospital and how many interfaces you run and how busy your server is compared to ours etc. If we can convert to Linux and prevent spending tens of thousands for a pSeries server...
I was able to realize you can change the MAC address in the .VMX (ensure the ethernet0.checkMACaddress=false is set and .type=static) and that will definitively make the "hardware" MAC address for the VM what you set it to in the VMX. The only problem with this is that if you attempt to edit the VMs configuration in the GUI and click on the NIC you get stuck. It recognizes the invalid MAC and won't let you do anything except click cancel. So if you need to change vSwitches you need to use the Inventory/Networking section of the GUI to do so, you can't do it in the VM configuration in the GUI.
Thanks for letting me know about getting stuck in the GUI. I will be doing a pretty extensive test myself sometime next week when time permits.
As for Cloverleaf, I asked our interface administrators and they said we are running almost 150 interfaces and process ~ 700K messages per day. We decomissioned an old P630 Power 4+ box. The Linux VM has 10 GB RAM and two vCPUs. It was originally built by someone else with less memory and a Flexible NIC type. We just recently had to change the virtual NIC to VMXNET2 and expand to 10GB RAM. With the new setting we are no longer getting messages that queue up.
Running into an issue forcing a MAC address not in VMwares OUI.
This worked just fine on my test server, but for some reason in my production environment I edit the .vmx file and start the VM and it decides to just overwrite the changes I made and regenerates the original, VMware assigned, MAC address.
I have no idea how to stop this behavior...
Just figured it out. Interesting.
Even though my other test VM was turned off, this other new test VM I was giving the same MAC address. VirtualCenter apparently was seeing this and was forcibly changing it back to the last known good MAC address. So I just gave it a completely new MAC and it accepted that. Shut it down, tried to give it the original (the dupe) and vCenter switched it back to the new custom one that did work.