So… imagine you have a KVM host, set up with a public bridge on
eth0 as described on the Debian wiki. The configuration seems to match exactly; yet when the bridge starts, connectivity is lost on the host. So although the guest VM is able to ping out to say; Google, the host has no outbound connection.
After a complete red herring involving this host being connected to a TL-WR702N wireless bridge; (does this mean I need to rewrite the MAC address of my VM?) and a digression into
ebtables – I finally struck gold with the output of
ip route which showed me that both the bridge (in my case
kbeth0) and my physical adapter (
etho) had the same IP.
That can’t be right! Makes you think about how you were so intent on this machine having LUKS encryption; but wanted to be able to shove it in a cupboard and decrypt remotely through ssh. And so when the machine boots off the
initrd I start up a
dropbear ssh server; assigning a static IP via the grub command line; and how perhaps that assignment persists after the disk has been decrypted and
kbeth0 comes up.
Turns out; adding an
ip addr flush dev eth0 to the end of
/etc/rc.local (just before the
exit 0) means that
kbeth0 is able to come up with the right ip address; having taken it off
eth0 – and all is right with the world once again. And – no need to fiddle about with
I can’t say i’m entirely sure of this hypothesis; but it seems to work – and now I can decrypt on boot remotely; while still bridging my network adapter to run virtual machines in KVM.