I've set up a virtual machine configured with bridge networking. After making eight clones of it, the new machines can't connect to the network.
I've instructed VirtualBox to re-generate the machines' mac-addresses.
I've set up a virtual machine configured with bridge networking. After making eight clones of it, the new machines can't connect to the network.
I've instructed VirtualBox to re-generate the machines' mac-addresses.
There are
udev
rules preventing the new interface from being brought up.In the Master machine, just delete them before you clone the new machines:
(source)
Refresh your MAC address using Virtual Box machine settings and remove the kernel’s networking interface rules file so that it can be regenerated:
It will work for your clone VM.
I was dealing with the same problem for months and today I decided I would find a better fix. Here is what I did on the machine I was using as a Template.
For good administration practices back up both files before editing.
You have two offending/target files:
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/udev/rules.d/70-persistent-net.rules
This will work for a
static
ordhcp
address:Open
/etc/sysconfig/network-scripts/ifcfg-eth0
Delete the MAC Address line:
HWADDR=XX:11:22:XX:33:XX
Save the file.
Delete the file
/etc/udev/rules.d/70-persistent-net.rules
"it will be recreated after you restart the VM"You can now clone your box and every clone will correctly deploy and display eth0.
If you do not use a template, you may complete these procedures on the actual VM just remember to re-initialize the NIC your in the VM software before you restart the machine.
I encountered the same problem on a previous version of VirtualBox and I read somewhere that there was a bug which rendered the "generate new MAC address" tick box useless.
I'm now using Ubuntu 12.04 with VirtualBox 4.2.10. I noticed now that when I created the clone, there was no tick box to "generate new MAC address."
This gave me some problems even if I deleted 70-persistent-net.rules because the system would automatically generate the file on startup with the same MAC address as the original, which made it fail to connect.
But I discovered that in VirtualBox Manager, you can select the clone, go to Settings>Networking>Advanced and generate a new MAC address by ticking the box.
So what I did was to delete 70-persistent-net.rules first, shut down, generate new MAC address and start again, and now it works.
Alternatively, you can delete the file first before you clone. Then generate MAC address, then start the clone. That ought to work as well.
I am building parallel computing environment that needs interconnection between the virtual machine through ip network.
I think there is something related to the re-generate the machines' mac-addresses. I had faced the similar problem before.
The original virtual machine has
eth0
andeth1
. But due to the regenerating process, in my case, the new cloned machine haseth2
andeth3
. you can check it by this following command:You can check with
ifconfig
command that in the new cloned machine has onlylo
registered. Generally, you should havelo
,eth0
, andeth1
when you typeifconfig
command.That is due to MAC regeneration that in the clone machine, there are
eth2
andeth3
Ethernet interfaces instead ofeth0
andeth1
in the original machine. You can also check the/etc/network/interfaces
in the original machine that in my case will appears like:May be you can modify your
/etc/network/interfaces
file and change theeth0
andeth1
witheth2
andeth3
, which more or less like this:So, good luck guys!
I deleted 70-persitent-net.rules file but it wasn't re-created after reboot. Then, re-installing guest additions module and rebooting the VM worked for me.
I have problem with same ip-address after cloning 3 VMs with Virtual BOX (4.3). SO I have power off the machines and regenerated new mac address and restarted it worked for me.
steps => switch off the cloned VM and then settings => network => advanced => click on refresh MAC address => clik OK. then start VM.
I was facing the same issue after cloning ubuntu-server-20.x image. I was using nat-service. What worked for me was the following.