Using MAC-Based Licensing with vSphere: A Necessary Evil

Should software licensing be completely based off of the hardware MAC address of the NIC and or UUID of the mother board?  This process worked very well before the introduction of virtualization but now that virtualization has become more prevalent in most environments. I think software venders really need to reconsider how they are going to license their software although it seems that some companies have not bought on to the idea of virtualization and would prefer to continue to support their product type to a specific hardware platform that the vender put together and shipped out.  Can software venders hope to survive and remain current without embracing virtualization? I think the answer to that question is going to be no in the long run. 

I was working with a client that had a custom application / appliance running on a specific physical hardware and the appliance is fully configured and shipped out as a complete server.  This is a perfect example of a product that in my opinion is something that should be available to run either physical or virtual.  It has been my understanding that there is really not a big margin when selling hardware so having the option to download and deploy the application as a virtual appliance seems like a no brainer to me.

I have been working with a small client lately and have been setting up their virtualization proof of concept. One of the tasks, of the project, was a few physical to virtual (P2V) migrations.  One of the servers on the list was basically a custom appliance running on an old dell server with an extremely specifically built version of Red Hat that I was unable to migrate using the vConverter.  I had the server listed as problem child before starting this project and was expecting to have issues.  One option that I wanted to try was to just do a clean build with the recovery disks that were sent by the vender. To say the vender was not very forth coming with information would be an understatement, but given the limited amount of information that was presented to me about the application itself, I was able to figure out that the install was failing because the licensing for the application was based on the MAC address of the system before it originally left the factory.

Once I realized that I would need to hardcode the old physical MAC address to the virtual machine, I started to do some searching to make sure this was still possible in vSphere5. I came across a lot of posts from people that were not able to get this process to work and I wanted to share the steps I followed to make the hard coding of the MAC address work correctly.

Technical Details

First step, which is very important, is to unregister the virtual machine if it is currently listed in the inventory. Removing the virtual machine from inventory will leave you the ability to edit the *.vmx file and get the changed information applied to the virtual machine when it gets registered back into the environment.

If you take a look at the entries for the vNic in the virtual machine’s vmx file, it will look something like this:

ethernet1.present = “true”

ethernet1.virtualDev = “vmxnet3”

ethernet1.networkName = “NETWORK01”

ethernet1.addressType = “vpx”

ethernet1.generatedAddress = “00:50:56:b5:6F:21”

ethernet1.features = “1”

ethernet1.startConnected = “TRUE”

You will need to make a change to ethernet1.addressType from “vpx” to “STATIC” and change the ethernet1.generatedAddress to Ethernet.address with the MAC address that come from the physical server we were migrating.  One more, very important setting, to add to help make sure the MAC address rules that VMware enforces is bypassed for this specific virtual machine is the checkMACAddress option.

Your changes so far should look like this:

ethernet1.checkMACAddress = “FALSE”

ethernet1.addressType = “STATIC”

ethernet1.address = “00:00:00:12:34:56”

Although everything looked like it was working correctly from this point, I was still not able to get the license to apply and the install to complete. I needed to make one other change and that was the vNic device from “vmxnet3” to “e1000”

ethernet1.virtualDev = “e1000”

Once I made the change to the vNic device, I re-registered the virtual machine back into inventory. I was asked during the registration if I had copied or moved the virtual machine. I selected “moved” so the settings would not be touched.  If I had selected copied then I believe all the custom MAC settings would have been overwritten.

From here, I started the virtual machine and re-started the licensing process and this time the license was able to be applied. The MAC coding was a success and once again all was well in the universe.

Update: It is also possible to use a similar technique within Hyper-V and Xen to set non-standard MACs for licensing purposes.

Conclusion

Licensing is a necessary to protect the intellectual properties of software companies, but the evil is that we are forced to use a method to “make it work” by not  having  options and support  in resolving licensing issues with some companies. Licensing should not have to be this difficult or as much of a hassle when trying to move applications from physical hardware to virtual.  It is understandable that when black box appliances are released, the” idea” is application will run on that hardware until its decommissioned or refreshed.  Virtualization, no matter which hypervisor it is running on, should have presented a change of thought to this “idea”. Virtualization has helped redefine software life-cycle in a lot of ways since once the application is virtual the application no longer depended on the specific hardware it is running on and to my point, either should the licensing.  Licensing needs to able to work in both physical and virtual worlds as well as make the migration between.