Cloned machine has no network

[John Poelstra]

I'm running virt-manager on Fedora 12.  I selected the option to 'clone' 
a machine from the menu.  The clone process worked great (mostly) and 
the cloned machine boots fine.

On the cloned machine the network card no longer works and trying to 
start eth0 returns an error message about the device not being present.

I gave the virtual machine a new nic, hoping that might solve the 
problem but I can't figure out how to configure it using command line 
tools. 'lspci' shows that it is present. I tried setuptools, but the 
changes didn't seem to take.

I'm running a really bare bones guest with no X.

Suggestions on how to move forward?

Thanks,
John

[Sven Lankes]

On Sun, Jan 17, 2010 at 08:00:47AM -0800, John Poelstra wrote:

>  On the cloned machine the network card no longer works and trying to
>
>  start eth0 returns an error message about the device not being present. 
[...]

>  I'm running a really bare bones guest with no X.
>  Suggestions on how to move forward? 
I'd guess that you still have the old machines MAC-Address in 
/etc/sysconfig/network-scripts/ifcfg-eth0 

-- 
sven === jabber/xmpp: sven(a)lankes.net

[Tom Horsley]

On Sun, 17 Jan 2010 17:00:30 +0100
Sven Lankes wrote:

>  I'd guess that you still have the old machines MAC-Address in 
>  /etc/sysconfig/network-scripts/ifcfg-eth0  
You also probably have eth1 instead of eth0 because there is
probably a /etc/udev/rules.d/*persistent-net* file out there
locking the eth0 name to the old mac. Deleting that file and
rebooting will create a new copy with the new mac called eth0.

[John Poelstra]

Tom Horsley said the following on 01/17/2010 08:25 AM Pacific Time:
>  On Sun, 17 Jan 2010 17:00:30 +0100
>  Sven Lankes wrote:
>
> > I'd guess that you still have the old machines MAC-Address in
> > /etc/sysconfig/network-scripts/ifcfg-eth0
>
>  You also probably have eth1 instead of eth0 because there is
>  probably a /etc/udev/rules.d/*persistent-net* file out there
>  locking the eth0 name to the old mac. Deleting that file and
>  rebooting will create a new copy with the new mac called eth0.
>  
Thanks!  Yes, updating the MAC in 
/etc/sysconfig/network-scripts/ifcfg-eth0 and 'rm 
/etc/udev/rules.d/*persistent-net*' plus a reboot made it work.

Would it be a viable RFE to suggest that the "cloning" operation would 
take care of this in the cloned guest automatically?

John

[Paul Jenner]

Hi John.

On Sun, 2010-01-17 at 19:28 -0800, John Poelstra wrote:
>  Thanks!  Yes, updating the MAC in 
>  /etc/sysconfig/network-scripts/ifcfg-eth0 and 'rm 
>  /etc/udev/rules.d/*persistent-net*' plus a reboot made it work.
>  
>  Would it be a viable RFE to suggest that the "cloning" operation would 
>  take care of this in the cloned guest automatically? 
I think that is Fedora bug #524269 already. At least it looks like
updates should live there.

Hope that helps,

Paul

[Richard W.M. Jones]

On Mon, Jan 18, 2010 at 10:24:08PM +0000, Paul Jenner wrote:
>  Hi John.
>  
>  On Sun, 2010-01-17 at 19:28 -0800, John Poelstra wrote:
>  > Thanks!  Yes, updating the MAC in 
>  > /etc/sysconfig/network-scripts/ifcfg-eth0 and 'rm 
>  > /etc/udev/rules.d/*persistent-net*' plus a reboot made it work.
>  > 
>  > Would it be a viable RFE to suggest that the "cloning" operation would 
>  > take care of this in the cloned guest automatically?
>  
>  I think that is Fedora bug #524269 already. At least it looks like
>  updates should live there. 
I think virt-clone doesn't necessarily "know" what is in the guest
disk image that it is cloning.  All it does it to copy the image and
write a new, updated libvirt configuration (new UUID, new MAC address
and a few other things like that).

We noted in the bug that this is a good place for libguestfs /
virt-inspector / guestfish.

Unfortunately the problem of cloning a guest properly is rather
open-ended.  For example would you want to run sysprep or modify the
registry if you found out that it was a Windows guest?  How would you
clone a Debian guest that had a fixed IP address in
/etc/networking/interfaces?

With virt-inspector we go into the guest and find out all about its
configuration, what kernel and apps are installed, and lots of other
details.  At the moment we DON'T get the guest's network
configuration, but we could, and it would be worthwhile.  But
virt-inspector is a sort of "open proprietary standard" and for a long
time I've been looking to get cross-party agreement on what an XML
file format that fully described guest configuration would look like.
(For existing efforts and examples see:
http://git.annexia.org/?p=libguestfs.git;a=tree;f=inspector;hb=HEAD )

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top