virtualbox.org

Host: debian "lenny", VirtualBox 3.0.10
Guest: debian "lenny", bridged networking

Networking on my guest OS only seems to work if it was created directly within VirtualBox, not when imported or copied.

I've spent all day trying to narrow this down to a simple, reproducible case, and I think I have it -- so hopefully someone can help me figure out why this isn't working, or if it's a bug. I looked in the ticket database and scoured this forum and the web, and am amazed nobody else is having this problem so it must be something I'm doing wrong. Any help would be greatly appreciated.

Here are my steps to reproduce the problem, all on the same host OS (see versions/distributions above):

1. Create a new virtual machine, the normal way, with bridged networking. (Including installing fresh Debian linux distribution.)

2. Boot the new virtual machine, and notice that you have a network. (ifconfig shows eth0 is set up, and active, and has an IP address; all is good.) [Before someone misunderstands and starts explaining how to set up bridged networking, please understand -- it works as expected here! I'd been using VirtualBox on a single host for a long time, and have tracked improvements in how virtual bridging works and I'm doing it the right way in 3.0 and have been. This problem only began when I got a second machine so I could do fail-over and was shocked that eth0 was gone on my cloned version.]

3. Shut down the new virtual machine cleanly.

4. Clone the virtual machine on the same host, using either of these two methods: either (a) export .ovf from VirtualBox GUI on host, or (b) make a copy of the .vdi file (via cp or tar to preserve dates/times).

5. On the same host, using the VirtualBox GUI, either (a) import the .ovf you exported above, or (b) create a new guest, pointing to the copied .vdi file.

6. Before booting, go to the settings for the new guest OS created in 5, and make sure the networking is set to "bridged" mode.

7. Boot the new copy of the guest OS (no other guests are running).

8. Notice that you have NO NETWORKING on the new guest. After successful boot, do "ifconfig" and see you only have the "lo" device, not "eth0". If you do "ifup eth0" you get the following errors:

SIOCSIFADDR: No such device
eth0: ERROR while getting interface flag: No such device
eth0: ERROR while getting interface flag: No such device
Bind socket to interface: No such device
Failed to bring up eth0.

I'm very frustrated by this. Before I can dive into using VirtualBox and setting up my real production application server, I want to be 100% sure I can easily copy it to another machine and run it if the primary fails. But I'm entirely dead in the water until I can get this working -- otherwise it's a waste of my time in case it turns out some fundamental issue is keeping me from doing this.

In fact, the original test was between two host OS's (same configurations, both running the latest VirtualBox 3.0.10 installation). But when that didn't work, after trying many different ways of troublshooting, I switched to just trying to make it work on a single OS, and still to no avail.

I am just incredulous that I'm the only person having this problem, so can someone tell me, is this just a simple problem and I'm blind to the way to resolve it? It's okay if you call me dumb. I just really am exhausted iterating on possible solutions all weekend.

Oh, and to be clear, I have tested many, many things in my troubleshooting. Here are a few:

* I tried switching the networking on the copy to "NAT" and still no network on the copied system.
* I tried unplugging/re-plugging in the ethernet cable (virtually speaking) from the console UI ("Devices > Network Adaptors > [ ] Adaptor 1"), but no effect.
* I can't find any log files with errors from VirtualBox. Where would those be? I looked everywhere. There doesn't seem to be a way for me to tell it I wanted debug logging, but again maybe I'm just blind.
* I tried same host and different hosts, same result.
* I tried changing the macaddr of the virtual ethernet just to see if that could be causing it, and no effect.
* I tried adding a second interface (eth0 is bridged, eth1 is nat) and still nothing! ifconfig says only lo is active. Though in this case, I *can* start eth1 using "ifup eth1" (after adding it to /etc/network/interfaces) and it comes up in NAT mode. But that's not what I need! In every experiment I've done, eth0 gives the errors above if I try to bring it up, regardless of which mode it's in.

My guess is that this isn't specific to bridged networking, since it happened with NAT as well above. But I really need bridged networking or this won't work for my needs. So please, please, please, someone help me.

Could it be something specific to Debian, where it's caching something about the eth0 device that makes it not recognize it at boot? There are no errors in the logs, though. I just can't understand why this would be happening, so any help would be sincerely appreciated.

Thanks.

Steve

sgoldberg wrote:I tried changing the macaddr of the virtual ethernet just to see if that could be causing it, and no effect.
...after adding it to /etc/network/interfaces...

MAC address would have been my guess also.
Is eth0 identified by MAC address, or bound to a specific MAC address, in /etc/network/interfaces (or elsewhere)?

So we're on the same page (sorry to repeat stuff you likely already know or have tried):
The new guest (either via OVF import or created) will have a different MAC than the original. The VM MAC address is changed using:
Settings>Network>Adapter n>(Yellow Cog)>Guest MAC Address, OR
VBoxManage modifyvm "<VMName>" --macaddress1 <mac>

Use (select VM)>menu Machine>Show Log... to see logs.

MarkCranness wrote:Is eth0 identified by MAC address, or bound to a specific MAC address, in /etc/network/interfaces (or elsewhere)?

No, the MAC address is not listed anywhere. I can change the MAC address on my original guest (the source before I copy it) and it still works fine.

MarkCranness wrote:The new guest (either via OVF import or created) will have a different MAC than the original. The VM MAC address is changed using:
Settings>Network>Adapter n>(Yellow Cog)>Guest MAC Address, OR VBoxManage modifyvm "<VMName>" --macaddress1 <mac>

In theory, I shouldn't have to change it (since the one I'm copying from isn't running when I test it, so either way it should just work, right?). How good is VirtualBox for disaster recovery if you can't just bring up a copy of the machine on a new host without twiddline MAC addresses? (Which I think means it shouldn't matter.)

MarkCranness wrote:Use (select VM)>menu Machine>Show Log... to see logs.

Nothing about having problems setting up the network in there, unfortunately.

But thanks for responding. Do you mean you have never had this problem when you make copies? Can you try the steps I list above and see if you get the same result?

Thanks.

Steve

Woah, I just made a discovery...

Looking at dmesg for the fifteenth time, I finally noticed this entry:

udevd: renamed network interface eth0 to eth1

Why is it doing that?! That fully explains why eth0 is not there after boot, and why my networking is all screwy (because of course the original guest OS was not configured for eth1 but rather for eth0).

That's definitely something I can work around, but argh! Why is it doing that? Any ideas?

Thanks.

Steve

OK, I see the problem, though still am slightly confused:

You were right, Mark, that the MAC address stuff is the issue. But that doesn't quite make sense to me. So maybe it's still a bug?

I discovered that there's a rule in /etc/udev/rules.d/70-persistent-net.rules that refers explicitly to the MAC address (in the hex form).

So for some reason, that causes it to do the renaming on boot since that MAC address doesn't match the one it's configured with.

Thus -- the problem is resolved by simply copy/pasting the original MAC address into the network settings for the cloned VM. Now it works perfectly (and is correctly bound to eth0 just as before).

However, I swear in the past I've been able to swap hardware (on a real machine) and boot off a disk that was on a different machine (with the same architecture) and it just came right up. So maybe I'm wrong but either way -- there really should be a FAQ entry for this situation. Isn't it quite common to want to move a VM from one machine to another?

I mean, the core value proposition of the "export/import" function is to allow you to put an application server together and then clone in N times over. How are you supposed to re-bind the network to the new MAC address manually each time? Especially since it's shown as decimal in the VirtualBox UI, and hexadecimal in the persistent-net.rules file (above). That's just annoying and painful, it can't be right.

Thanks.

All you have to do is remove the entry from /etc/udev/rules.d/70-persistent-net.rules before exporting your VM. On first boot the entry will be written, so you won't have to manually edit the address.

Cannot this issue be fixed in VirtualBox? I came across this issue today. And got it work by changing the MAC address in guest os /etc/udev/rules.d/70-persistent-net.rules

Exporting Host:
Mac OSX 10.5
VirtualBox 3.2.10

Importing Host:
Mac OSX 10.6
VirtualBox 3.2.12

Guest OS:
Debian 5.03

And actually this is not the issue only with Linux Host. The same issue exists in Mac Host and Debian Guest.

This is a Linux *feature* that when ever you change the MAC address it ups the eth*
You can edit the /etc/udev/rules.d/70-persistent-net.rules or you can delete the rules and Linux will configure it on the next boot

Perryg wrote:This is a Linux *feature* that when ever you change the MAC address it ups the eth*
You can edit the /etc/udev/rules.d/70-persistent-net.rules or you can delete the rules and Linux will configure it on the next boot

OK. Then why not just keep the MAC address of guest os as same as it was before exporting?

And Maybe I should post the above question as a new topic on another board here?

If I understand you, that's the problem -- for easy migration of a guest on a down host to a new live host, you really don't *want* to have to change any files inside the guest OS and you wouldn't do it before because you wouldn't know you need to until you've lost the host and thus can't get at the guest except its latest backup image.

You want everything identical, including the MAC address, and for it to "just work".

That said, I do believe maybe the latest OSE version of VirtualBox is doing this "right" because I re-ran this experiment (without changing anything) a few weeks ago before this thread flared up again, and didn't have the same issues at all (i.e., it worked as it should, no need to edit any config files).

I'm slightly confused which version I'm using, but in the help it says Oracle VirtualBox Version 3.2.11 Edition, though the debian package refers to it as the open-source edition, i.e., virtualbox-ose version 1.6.6-dfsg-3.

Does anyone know if maybe this "problem" was resolved in version 3? Because I haven't had the problem in a while. Or maybe my work-around was so good, and I can't remember what it was, that I'll get bitten again later?

Thanks.

Steve

Hi Steve

I just ran into what appears to be the same problem as you with VirtualBox 4.0.4.

I'm also copying a .vdi across from one machine to another as a test of a disaster-recovery scenario, but getting no network on the clone. I get the same eth0 renamed to eth1 message in dmesg.

I'll try the solution of fiddling with the MAC address, but I agree 100% with you that this should just work: copy the .vdi, start it up and away we go ...

Jules

Thank you so much, it took me hours to solve it..

Just need to comment all these lines in the:
/etc/udev/rules.d/70-persistent-net.rules

Save my day... happy weekend all ...

I had the same problem this morning. I have also had this issue when swapping disks around in physical machines.

I could be wrong, but I really think you want to change the MAC address if it is going to be on the same switch/router. Otherwise it will be indeterminant which system you will be talking with and cause you to pull out your hair. There is a reason that hardware MAC addresses are guaranteed to be unique.

You could possibly turn off UDEV on the source VM and then the copied VM's should just work.
Preferably just remove the non comment lines from /etc/udev/rules.d/z25_persistent-net.rules before making copies. Then on first boot, new rules will be written.
If you forget to remove them first from the source VM, just boot the copied VM, and remove the rules as above, and then reboot.

CW

sgoldberg wrote:Woah, I just made a discovery...

Looking at dmesg for the fifteenth time, I finally noticed this entry:

udevd: renamed network interface eth0 to eth1

Steve

Steve-o,
You just pro'lly saved me 20 hours of searching + reinstall work with your old post.
Would have never thought to do a on this issue.

I just adapted the /etc/network/interfaces for eth2 (yes it renamed eth0 to eth2 for me) and added the new mac to my dhcp server.
and done !

btw, using
- virtualbox-4.1 (apt package)
- ubuntu server 3.2.0-12-generic
- phpvirtualbox