Red Hat Bugzilla – Bug 647174
RHEL6: virt-clone should remove old udev rules when changing MAC address
Last modified: 2013-01-27 02:40:16 EST
+++ This bug was initially created as a clone of Bug #524269 +++ When cloning a virtual machine like so virt-clone -o Guest1 -n Guest2 -f /var/lib/libvirt/images/Guest2.img Everything works. Minor 'issue' (if you can call it that) is that the network interface in the new machine shows up as eth1 instead of eth0. This is because /etc/udev/rules.d/70-persistent-net.rules contains lines telling the system to call the interface with the old mac address eth0. This 'new' interface thus gets the next available name. If possible I think on machine clone with a new mac address either the file should be updated with the new mac address (probably would make people the happiest in case they edited it by hand), or the file should be wiped clean so it can be built again from scratch. I also sorta feel like /etc/sysconfig/network-scripts/ifcfg-ethX should have HWADDR line mapping done as well. --- Additional comment from rjones@redhat.com on 2009-09-18 11:51:21 EDT --- Obvious application for libguestfs. Also CC-ing Matt Booth, because there is some overlap with the sort of modifications that virt-v2v does. --- Additional comment from fedora-triage-list@redhat.com on 2009-11-16 07:37:22 EST --- This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping --- Additional comment from rjones@redhat.com on 2010-01-26 12:29:00 EST --- Discussion on list here: http://lists.fedoraproject.org/pipermail/virt/2010-January/001784.html --- Additional comment from crobinso@redhat.com on 2010-02-26 19:22:42 EST --- *** Bug 544729 has been marked as a duplicate of this bug. *** --- Additional comment from renich@woralelandia.com on 2010-03-18 01:22:02 EDT --- Nice discussion... what's the status on this? --- Additional comment from crobinso@redhat.com on 2010-03-18 12:25:08 EDT --- Nothing yet. There is some more info here: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/345234 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431190 Debian carries a patch to fix this issue in udev for VMWare guests, though nothing upstream. The same type of fix could be applied for KVM guests. I'll bring it up on the udev list.
*** Bug 622804 has been marked as a duplicate of this bug. ***
This issue is kind of a pain. Currently virt-clone doesn't mess with the content of the guest, and I don't know if we should take the current tool down that route (certainly not by default). I know rjones and mdbooth have considered/investigated making a new virt-clone tool that uses libguestfs, and would alter the guest config similarly to virt-v2v. Certainly virt-v2v already has solved a lot of the problems we would face for properly editting a guest image after cloning. At the very least we should have a kbase article for this.
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as an exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Since there still isn't really a fix for this, deferring to 6.2. There is a kbase article for cloning apparently: https://access.redhat.com/kb/docs/DOC-53236
It's unclear at this time if we will ever alter the existing virt-clone tool to poke into guest disk images and make changes like this, it may very well end up being another tool, so it's difficult to say if this is 6.2 material. Deferring to 6.3
Since this isn't going to be solved by the existing virt-clone tool, it doesn't make much sense to track against python-virtinst. Reassigning to libguestfs.
We'll fix this by providing the updated virt-sysprep and virt-sparsify tools in RHEL 6.3 (bug 719879).
dev-acking on the basis that the new virt-sysprep tool will be enough to fix this bug.
Verify this problem with libguestfs 1.16.18-2.el6. Version: libguestfs-1.16.18-2.el6.x86_64 libguestfs-tools-1.16.18-2.el6.x86_64 libguestfs-tools-c-1.16.18-2.el6.x86_64 The virt-sysprep reset the image by change the network configuration: 1. remove the file: /etc/udev/rules.d/70-persistent-net.rules 2. remove the MAC address in the ifcfg-ethX This is OK to make the network work on the new cloned image. Also did sanity test for other operations within this tool: cron-spool dhcp-client-state dhcp-server-state hostname logfiles mail-spool net-hwaddr random-seed rhn-systemid smolt-uuid ssh-hostkeys udev-persistent-net utmp yum-uuid The corresponding operation can be executed without any problem. Mark this problem VERIFIED.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: The virt-clone tool does not know how to modify the internals of a disk image when cloning. Consequence: When using virt-clone, various state from the previous guest would remain in the new guest. In particular, udev rules referring to the old network would remain, causing a brand new interface to be brought up on the new guest (with a new name, eg eth1). Fix: We have provided two new tools: virt-sysprep can "cleanse" old state from guests, and virt-sparsify which can make guest images sparse. Result: Users should use virt-sysprep and virt-sparsify either as a replacement for, or in conjunction with, virt-clone. See the man page of virt-sysprep for full instructions: http://libguestfs.org/virt-sysprep.1.html#copying_and_cloning
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0774.html