CentOS, a "genericized" version of Red Hat Enterprise Linux, has been my server OS of choice for several years now. It has all the acceptance and compatibility of Red Hat Enterprise, without the heavy cost for updates. It has a long support lifespan, and follows the policy of backporting patches, so updates should not affect the configuration of running services.
My employer is releasing a brand new version of their core software offering, and I have been working to put together a new template image from which we can deploy new systems. With the relatively recent release of Red Hat Enterprise Linux 6 (and thus CentOS 6) and the major updates to the software that came with that, it seemed the obvious choice from which to assemble this new template.
In our hosting environment, we are running VMware Infrastructure 3i, using ESXi 3.5. I have plans to upgrade the hosts to a much more current version of vSphere, but the window for that has not yet presented itself! All of our production VM guests are using the vmxnet ethernet adpater.
Building the template in this environment proved easier said than done - The OS would install just fine in the template VM (I went with a "minimal" install, so as to keep the template as lightweight as possible), but once I tried to deploy a second system from the template, I could not get the network to come up. The VMware Tools and associated drivers (when downloaded from a 3.5 update 6a host) would build with no trouble.
After several false starts and ample searching, I found that there had been a few changes made to the behavior of device detection in the switch from RHEL 5 to RHEL 6, and the impact that was having was being felt in the changes that happen to a VMware network interface when one deploys a new cloned VM from a template.
Whenever you deploy a clone from a template, you have a VM that is identical in *most* regards to the template - except for a few minor identifiers, as well as a new MAC address on the cloned system's network adapters. This change leads udev to behave as though the adapter is new (and that the adapter with the template's MAC address is simply not present - but the configuration remains). As such, you have a eth0 that will not start, and an eth1 that is not configured.
Simple solution, based on findings at Aaron Walrath's blog:
On any template from which you will be deploying CentOS 6 machines:
Step 1: Remove /etc/udev/rules.d/70-persistent-net.rules
Step 2: Remove the HWADDR entry from /etc/sysconfig/network-scripts/ifcfg-eth0 (left in default DHCP configuration)
Step 3: Shutdown the system, convert it to a template
You should now be able to deploy CentOS 6 (or presumably RHEL 6) without network issues.
Subscribe to:
Post Comments (Atom)
1 comment:
You may want to migrate to CentOS 7 (coming soon) with vSphere/ESXi 5.5 when the opportunity presents itself, provided all of your hardware is a good match. That stack refresh would bring you "up-to-date" and likely provide significantly more capability over the 3.5/6.x pairing.
Post a Comment