Specifically, setting up bridged networking under Linux to enable a KVM virtual machine. I had this working just fine up until the point where I upgraded this server to hardy, whereupon everything fell apart. Thanks to the folks on freenode.net/#kvm, I discovered that my interface configuration was broken.

To summarise, I have:

1 Physical network interface
3 IP addresses (2 of which are assigned to the host OS, one to the guest VM).

It turns out that if you have a bridge set up on the interface, assigning a second IP address should be an alias to the bridge, not the first IP’s interface.

Initially, I had something like this:

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
        address xxx.xx.xxx.xxx
        netmask xxx.xxx.xxx.xxx
        broadcast xxx.xx.xxx.xxx
        gateway xxx.xx.xxx.xxx
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

auto eth1
iface eth0:1 inet static
        address xxx.xx.xxx.xxx
        netmask xxx.xxx.xxx.xxx
        broadcast xxx.xx.xxx.xxx
        gateway xxx.xx.xxx.xxx

There are several things wrong with this. The first is that the gateway should not be specified on the second interface. It wasn’t a problem in gutsy, but hardy did things somewhat differently, with the result that networking was completely disabled on reboot. IPMI to the rescue, fortunately.

Having fixed that, things seemed to work ok, but I was informed that the secondary IP should more accurately be assigned to the bridge, like this:

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
        address xxx.xx.xxx.xxx
        netmask xxx.xx.xxx.xxx
        broadcast xxx.xxx.xxx.xxx
        gateway xxx.xx.xxx.xxx
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

iface br0:0 inet static
	address xxx.xx.xxx.xxx
        netmask xxx.xxx.xxx.xxx

One swift edit, and things are working swimmingly well. One of the folks on freenode #kvm hinted that he might spend some time soon writing some, you know, documentation on this process, so in future it won’t require reading dozens of blog posts (like this one) to understand what the hell you’re doing. Sounds like a great plan to me. The most defining characteristic of the current documentation is that it’s almost as shallow as Paris Hilton, and decidedly less thick too.