I probably have the same issue.

Copied the guest to a new directory, opened it, created new uuid, and started the new guest.

Dmesg looks ok, eth0 is there (pcnet-something), it is in ifconfig, but can not ifup it.

I thought it could macaddress problem, changed it in the .vmx file, rebooted, and it came up as eth1.

I made another copy of the original, and changing eth0 to eth1 in /etc/network/interfaces made it work after ifup eth1. (probably with the same mac as original guest, if mac isnt changed at the same time as uuid.

host and guests are ubuntu 6.06 server.

host is standard install , but upgraded (current) yesterday

Here is a script that should sort you out. I ran into the same problem and this was my way of fixing it. I'm sure it's not the best, but it works. Save it (I called it "fixmac") and put into /usr/sbin/ on your "base machine". Then, after shutting down and copying your base machine, boot the new machine, log in, and execute "fixmac" as root. Reboot and your interface should start working.

\---- Start Script -

mac=`ifconfig -a | grep "HWaddr" | cut -d " " -f 11`

echo "eth0 mac $mac arp 1" > /etc/iftab

\---- End Script -

I hope that helps!

Here is a script that should sort you out. I ran into

the same problem and this was my way of fixing it.

I'm sure it's not the best, but it works. Save it (I

called it "fixmac") and put into /usr/sbin/ on your

"base machine". Then, after shutting down and copying

your base machine, boot the new machine, log in, and

execute "fixmac" as root. Reboot and your interface

should start working.

 

---- Start Script ----

 

mac=`ifconfig -a | grep "HWaddr" | cut -d " " -f 11`

echo "eth0 mac $mac arp 1" > /etc/iftab

 

---- End Script ----

 

I hope that helps!

Quoted because this solution fixed a cold migration of an Ubuntu 6.06 (LAMP) server from ESX 2.52 --> ESX 3.0.1. Initially the server showed no known interfaces even after upgrading VMTools. After this script ran and the VM was rebooted eth0 was back up and running normally.

It did help, thank you!

Hi,

your problems sound exactly like the problem we ran into when cloning a Debian installation.

The root of the problem at our site was udev's handling of devices. Udev keeps a history of devices attached to the computer. What makes sense for i.e. USB sticks (that is, each USB stick you attach will be recorded and mounted to the same point when attached again at a later point in time), causes problems when systems are cloned.

There is a file /etc/udev/rules.d/z25_persistent-net.rules, where udev memorises, which hardware device should get named eth0. Here it looks like this:

\# PCI device 14xx:16xx (tg3)

ACTION=="add", SUBSYSTEM=="net", DRIVERS=="?*", SYSFS\{address}=="00:11:xx:xx:xx:xx", NAME="eth0"

When you run the image on another computer, the new network adapter is recognised on the PCI bus and a new entry in the above mentioned file is generated. "eth0" is already given to device 14xx:16xx, so the new device gets named "eth1".

If you delete this file, it will be rebuilt during the next system startup and your problem should go away.

Regards,

Rainer

just want to add that i had the same problem migrating a ubuntu guest from a vmware server to a esx server.

After migration the eth0 device was not present.

Solution was for me too, to see after the HW Adress in the new vmx file and write this HW Adress in /etc/iftab.

hope this helps other people too.

thx  a lot + greets

Thank you!

this is infact the REAL solution...... for debian at least