Description of problem: After cloning a RHEL6 virtual machine with a working network interface, the clone's network interface does not work. This problem has been seen on Fedora 18 and Fedora 17 host machines. After cloning a Fedora 18 virtual machine, this problem does not occur. Version-Release number of selected component (if applicable): virt-manager-0.9.4-4.fc18.noarch libvirt-0.10.2.3-1.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. Create a New virtual machine. 2. Install RHEL6.3 in the virtual machine. 3. Boot the virtual machine, login and run "/sbin/ifconfig". 5. Observe that eth0 is displayed in the ifconfig output. 4. Shutdown the virtual machine. 5. Clone the virtual machine, accepting default settings in the Clone dialog. 6. Boot the clone VM. 7. Login and run "/sbin/ifconfig". 8. Observe that eth0 is not shown in the ifconfig output. 9. Run "/sbin/ifconfig eth0 up". 10. Observe that ifconfig fails with "No such interface" 11. Run "lspci" 12. Observe that the lspci output includes a VirtIO Ethernet Controller. Actual results: The clone VM does not have an eth0 interface. Expected results: The clone VM should have a working eth0 interface. Additional info: None.
Known issue, see the bit about persistent net rules here: http://www.havetheknowhow.com/Configure-the-server/KVM-clone-a-vm.html There's a standalone tool called virt-sysprep that will handle this bit, we need to document using it in the virt-clone context though. Duping to that bug *** This bug has been marked as a duplicate of bug 878170 ***
I don't think it's valid to mark this as a duplicate of the man-page bug. If you're using the virt-manager GUI, you don't know (or care) what command-line tools are being run behind the GUI (and without knowing that virt-clone is called by the GUI, how am I supposed to look up its man-page and discover the missing step?). If it takes two steps to properly clone a VM, then the logic behind the GUI should run both of those steps without the user having to magically discover the secret extra step. Every virt-manager user who clones a RHEL VM will run into this problem. Expecting them to find the solution in the man-page for a hidden internal component of virt-manager just won't cut it if we want users to have a good experience with virt-manager.
yes that was a bit hasty, apologies. I should have elaborated. Running virt-sysprep from virt-manager/virt-clone isn't entirely straightforward: - doesn't work on remote hosts - pulls in libguestfs which has a large dependency chain so we can't 'Require' it. though we could use it if available - running virt-manager often doesn't have the appropriate auth to actually run virt-sysprep on the user's disk images. at best we'd get a separate auth dialog now that libguestfs uses libvirt, but I haven't confirmed that's actually the case. - We can add a scary warning like 'your new VM network might not work blah blah' but that's also not accurate for modern Fedora so showing it unconditionally has downsides. And we still don't have good VM OS tracking in virt-manager The simplest thing to do would be add a warning to the virt-manager clone wizard that networking might not work for some OS and point to virt-sysprep as the solution, I've added a comment to the dup'd bug about that issue. So there's certainly room for improvement here but also a ton of caveats. And since people seem to make do with the existing clone functionality it's never really become a priority for virt-manager development. We had other bugs tracking this integration that just collected dust forever and were eventually closed. Which unless someone steps up to try and figure these things out is likely what will happen with this report as well.
*** Bug 878170 has been marked as a duplicate of this bug. ***
Upstream virt-manager and virt-clone now have warnings and documentation that mention virt-sysprep is required to make actual changes inside the guest. In reality, I don't think the two tools ever will be integrated: we certainly can't switch to running virt-sysprep by default since it will break many uses of the tool and is too much a change in behavior, and trying to wire up command line options to call out to virt-sysprep won't provide much value over just pointing users at the tool and letting them figure it out themselves. So until someone comes up with a better idea, closing this as UPSTREAM.