Tonight my human and I sat down to an evening of belly-rubs and Linux installations on XenServer. Things were going swimmingly until we noticed that CentOS 5.10 kept hanging (on a network install) at the "Retrieving /images/stage2.img" step.

We had configured our VM to use 192.168.1.64 as a static IP address. My human had already decided to start counting backward from .68 for VM addresses (for reasons which are arcane and foolish) and this new VMjust had to be on .64.

We looked at the Performance tab in XenCenter and saw that network activity would rise for a moment and then fall down to almost nothing. On a hunch, I told my human to stop the VM (effectively trashing it, since we didn't finish our install,c'est la vie)and then ping to see if any other devices on our network were already using 192.168.1.64.

To his surprise, it turned out there was already another device assigned to that address. After a couple rounds of using nmap to discover open ports and guess-the-OS (to figure out what device might be causing the trouble), all we could determine about this device was that it was accepting TCP connections on port 8080 (though it apparently serves no content when actually trying to make an HTTP connection).

Out of frustration, my human decided to try the "unplug stuff until the ping goes dead" method of device discovery. And after a few wrong guesses (not the printer, not the Roku box) he finally identified the culprit as the UVerse TV Box.

(Had he stopped to think for a moment, he might have used RARP or simply looked at the lovely control panel for the UVerse router to determine the MAC address of the offending device, and used that to identify it using a MAC address lookup site).

So how to fix the conflict permanently? First, we shouldn't be using static addresses without adjusting the DHCP range on the router. Instead of using the entire 192.168.1.0/24 subnet for DHCP, let's change that to just the top half (more or less):

dhcp

Note: you will need to unplug your UVerse box and plug it back in again to ensure the new DHCP reservation is picked up.

Of course, changing the DHCP range means that any DHCP assignments will need to be changed also. For example, we have a webcam that my human uses to spy on me while he is away that had previously been assigned to 192.168.1.81; we will either need to configure the camera itself to use a static IP address of 192.168.1.81, or change the assignment to something inside the new DHCP range. (To do that, we went to Settings > LAN > IP Address Allocation and pick out a new private IP address for the webcam).

As far as whether to use static IP addresses or DHCP assigned IP addresses… generally for VMs, it seems to make sense to put them as static IP addresses, particularly if they are test servers that are liable to be created and destroyed (or have their MAC addresses changed) frequently. Having to go to the router to reconfigure a static DHCP assignment is a pain in the neck; but of course using random DHCP assignment isn't good either because you'll have to go hunt down your VM every time it is restarted. Better to just manually configure the TCP/IP stack with a static IP address, and keep DHCP's stinkin' paws off of it.

Whereas physical devices, since they aren't liable to be created or destroyed, they should probably be given a static DHCP assignment, or (for things like laptops and phones) random DHCP addresses, for the sake of security.