Bug 647174 - RHEL6: virt-clone should remove old udev rules when changing MAC address
RHEL6: virt-clone should remove old udev rules when changing MAC address
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libguestfs (Show other bugs)
6.0
All Linux
high Severity high
: rc
: ---
Assigned To: Richard W.M. Jones
Virtualization Bugs
: Triaged
: 622804 (view as bug list)
Depends On: 524269 libguestfs_rebase6.3
Blocks: 747123 727267 747667 756082
  Show dependency treegraph
 
Reported: 2010-10-27 09:33 EDT by Chris Tatman
Modified: 2013-01-27 02:40 EST (History)
21 users (show)

See Also:
Fixed In Version: libguestfs-1.16.2-1.el6
Doc Type: Bug Fix
Doc Text:
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
Story Points: ---
Clone Of: 524269
Environment:
Last Closed: 2012-06-20 02:59:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Chris Tatman 2010-10-27 09:33:15 EDT
+++ 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.
Comment 2 Cole Robinson 2010-12-01 11:40:17 EST
*** Bug 622804 has been marked as a duplicate of this bug. ***
Comment 3 Cole Robinson 2010-12-01 12:31:32 EST
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.
Comment 4 Suzanne Yeghiayan 2011-03-28 17:14:21 EDT
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.
Comment 6 Cole Robinson 2011-04-07 11:58:12 EDT
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
Comment 9 Cole Robinson 2011-06-10 16:06:59 EDT
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
Comment 14 Cole Robinson 2011-12-09 18:27:52 EST
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.
Comment 15 Richard W.M. Jones 2012-01-09 16:08:53 EST
We'll fix this by providing the updated virt-sysprep and
virt-sparsify tools in RHEL 6.3 (bug 719879).
Comment 16 Richard W.M. Jones 2012-01-30 06:21:57 EST
dev-acking on the basis that the new virt-sysprep tool
will be enough to fix this bug.
Comment 19 Qin Guan 2012-04-18 05:47:44 EDT
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.
Comment 20 Richard W.M. Jones 2012-04-26 09:13:12 EDT
    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
Comment 22 errata-xmlrpc 2012-06-20 02:59:20 EDT
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

Note You need to log in before you can comment on or make changes to this bug.