Posterous theme by Cory Watilo

Filed under: virtualization

D’oh – VMware conversion and static IPs

So we converted all of our testbed servers from the venerable VMware Server 1.0 product to the sexy, but also free, ESXi product.  Server was getting a bit a bit long in the tooth, but we definitely had reason to be wary of the VMware Server 2.0 product based on our experience with the beta causing what appeared as disk hardware errors.  That is another story.
The point is, moving to ESXi is beneficial in a lot of ways, mostly to do with the serious hardware we put underneath it.  Multiple snapshot support is another nice benefit to mention.  However, the conversion process had one gotcha up its sleeve…network adapter changes.
The network adapter is definitely part of the virtualization performed by VMware, drivers for which are included with the VMware tools installed on the guest.  During the conversion process, I failed to notice that these were replaced with the ESXi tools, which caused the OS to recognize a new network adapter.
All of our testbed systems are individual Domain Controllers of their own domains, along with Exchange being installed.  This configuration didn’t break at first, thankfully.  The big issue is that if you are doing domain stuff with these boxes anywhere outside them, such as adding a computer to the domain, the other machine needs to know the DC.  Normally this is gotten through DHCP and DNS.  In this case, we have loads of these separate DCs on the same network, so they can’t very well all be DHCP servers.  Instead the DC has to be hardcoded into the client as the DNS server.  This is why all of the testbeds have static IPs assigned.
Until you replace their network cards and forget to reassign the static IP.
So remember this if you end up converting VMs with static IP configs.

Relocating TeamCity build agents

I logged into TeamCity today and was surprised to see no active agents.  Further investigation showed that I had entirely lost the connection between the server and the agents.  This is bad.
Fortunately, there was nothing seriously wrong.  We had moved the build agents and build server to a new VM server, which had necessitated converting the VM format and installing a new set of VM tools (VMware Server => ESX).  Evidently this was enough to confuse the TeamCity server.
After verifying that IP connectivity was working, I restarted build agents.  Upon restart, the agents reconnected to the server, however they were not recognized as the same as before.  This means I lost the configuration associated with these build agents.  Since our build agents are specialized to build for different environments, I lost the mappings for particular projects to go to particular build agents.
Fortunately, TeamCity makes this kind of stuff pretty easy.  A few clicks later and I was back in business.  While it would be nice if TeamCity were a bit more resilient to changes and could recognize the agents better, this wasn’t too difficult.