VMware API error: “Customization of the guest operating system ‘rhel6_64Guest’ is not supported in this configuration”
While using VMware’s API and pyVmomi to clone templates into a VM, a couple of times I have run into this error:
Cannot deploy template: Customization of the guest operating system ‘rhel6_64Guest’ is not supported in this configuration. Microsoft Vista (TM) and Linux guests with Logical Volume Manager are supported only for recent ESX host and VMware Tools versions. Refer to vCenter documentation for supported configurations.
For me this happened when (A) I was cloning a RHEL 64-bit template (this occurred both with RHEL 6 and RHEL 7 but for entirely different reasons on each), and (B) I was using a customization specification. We had just stood up a new datacenter and I was laying the groundwork for creating masses of virtual machines from a command-line. A Linux command-line, mind you. Not from PowerCLI or PowerShell (which are certainly powerful, but hey, I’m a Linux guy).
In my case, the error had nothing to do with logical volumes (I suspect that’s true for most people who have run across this message). I have a script that has been happily cloning 64-bit LVM-based RHEL 6 templates in multiple vCenters that are on versions between 5.0 and 5.5. Since my customization spec was setting network parameters, I suspected that’s where the root of this problem was. So, before you go chasing that wild goose of LVM incompatibility, or telling vCenter your template is RHEL 5, I have a couple of recommendations.
In most of these cases, you’ll need to convert your template to a VM and power it up, then make the changes, shut it down, and convert it back to a template.
1. If this is happening with RHEL 7, make sure the vCenter is a new enough version to support it
One of our vCenters had not been updated in some time. When I tried cloning the same RHEL 7 template from an updated vCenter (and had the correct VMware tools installed) all went well.
2. If this is happening with RHEL 6, Make sure your version is 6.4 or later
There were some updates in 6.4 that greatly improved RHEL’s interaction with VMware’s hypervisor, including at the NIC level.
3. Install VMware tools on the template VM
This is the biggest source of problems. If you’re using customization specifications during cloning, VMware cannot do the work unless the tools are installed in the image from which you’re cloning. I like using the “3rd party” tools that you can get from VMware’s own repo. You can clone that repo into your own, or just use theirs. You can even bring it into Satellite or Spacewalk, either as an external repo or a software channel. Or maybe you like doing it the old fashioned way and installing them from vCenter. Bottom line – install those tools!
For RHEL 6 that means “vmware-tools-plugins-deployPkg” has to be present. It will be if you simply install “vmware-tools-esx-nox” (I also include vmware-tools-esx-kmods).
For RHEL 7, you need open-vm-tools (which comes standard with RHEL 7) and open-vm-tools-deployPkg (which comes from VMware). Note: If you’re using CentOS 7, open-vm-tools-deployPkg requires open-vm-tools < 9.5. This created issues for me trying to install in CentOS 7.2, which ships only 9.10. The solution? Disable all repos except vmware-tools and C7.1.1503-base from the “vault” when you do the installation.
yum –disablerepo=* –enablerepo=vmware-tools –enablerepo=C7.1.1503-base install open-vm-tools-deployPkg
By the way, the symptoms of this in RHEL 7? Aside from the customization error, you’ll have network cards named ens32 or ens33 in the template, but ens160 in the clone. And obviously, networking will be broken.
Also, get rid of the udev stuff that sometimes messes up your NIC settings
This applies more to RHEL 6. If you clone from a template, VMware will naturally give the new machine a new MAC address for any NICs in the template. In a single-NIC configuration, when udev sees this, it says, “Hey, I this isn’t the MAC for eth0, so let me make a configuration for eth1 using this new MAC and UUID.” You can help yourself here by doing the following (per VMware’s advice):
-remove /etc/udev/rules.d/70-persistent-net.rules
-remove /lib/udev/rules.d/75-persistent-net-generator.rules
You might not need to remove /lib/udev/rules.d/75-persistent-net-generator.rules, but I don’t think it’ll hurt. When I did these things to my RHEL 6 template, I was able to clone just fine using the API again.