My situation is a virtual machine image that I want to use in multiple places, running it on multiple host systems (it lives on an external disk drive, so it’s easily taken to these various places). The host systems in my experiments are all Windows 7 boxes.
The symptom is that, when booted in a new environment, networking in the guest Linux installation doesn’t come up. Specifically, I see IPv6 addresses assigned but not regular Inet addresses. Sometimes, the boot brings up the setup utility (but there’s nothing I’ve found to configure the network in a way that’s useful there).
It appears that fairly common network init code in Linux is remarkably unstable when a disk (or disk image) is migrated from one real or virtual system to another. This code seems to exist in a wide range of Linux distributions, but my actual experiments have been with Centos 6.4 guest systems in a Virtualbox VM.
The root cause seems to be that Linux stores a UUID for the network connection and the MAC address both in /etc/sysconfig/network-scripts/ifcfg-eth0 and /etc/udev/rules.d/70-persistent-net.rules. When you create a new virtual machine, you get a new MAC address (and it asks you if you want that even if you copy one). And you really don’t want multiple machines with the same MAC address operating in the same LAN segment (or larger bridged network).
The solution is, after booting the new virtual machine from the old disk image, to log in and do some configuration editing. (Note: Since the network doesn’t come up, you can’t get in via SSH. And you can’t paste into the Virtualbox console window. Thus you must know a password for a sudo-capable account, and type it in manually. Given my penchant for 20-character random passwords, this was a royal pain.) Specifically, I deleted the hardware (MAC) address and the UUID lines from ifcfg-eth0, and the entire line referring to etho from 70-persistent-net.rules. I then rebooted the system. (There are arguments that just restarting the network would suffice, but when I tried that earlier this afternoon it did not appear to work. I have not investigated that bit further.)
I also had a huge amount of trouble finding clear enough discussions on the web, and had to do a lot of experimenting to get this result. And I had enough cases of a VM that brought up networking one boot but not the next that I’m a bit worried still.
Yeah, the persistent assignment of network device to adapter (MAC address) is a big pain, and one that needs a better workaround. I think ours is to use a neutered distro for anything we clone a lot. 🙂 But another thing I’ve seen is to a second network config ready to go on eth1, which only helps the first generation of clones.
I should look at the second adapter idea; that solves the problem of not being able to SSH in on first bootup (you then need to reset things for further copies). (I’ve also added a user named “ip” with a simple password that runs a script that just displays the IP address it got from DHCP, so I would know where to SSH to.)