RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 647174 - RHEL6: virt-clone should remove old udev rules when changing MAC address
Summary: RHEL6: virt-clone should remove old udev rules when changing MAC address
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libguestfs
Version: 6.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 622804 (view as bug list)
Depends On: 524269 libguestfs_rebase6.3
Blocks: 727267 747123 747667 756082
TreeView+ depends on / blocked
 
Reported: 2010-10-27 13:33 UTC by Chris Tatman
Modified: 2018-11-14 14:05 UTC (History)
21 users (show)

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
Clone Of: 524269
Environment:
Last Closed: 2012-06-20 06:59:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0774 0 normal SHIPPED_LIVE Low: libguestfs security, bug fix, and enhancement update 2012-06-19 19:29:50 UTC

Description Chris Tatman 2010-10-27 13:33:15 UTC 
+++ 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 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 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 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 on 2010-02-26 19:22:42 EST ---

*** Bug 544729 has been marked as a duplicate of this bug. ***

--- Additional comment from renich on 2010-03-18 01:22:02 EDT ---

Nice discussion... what's the status on this?

--- Additional comment from crobinso 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 16:40:17 UTC 
*** Bug 622804 has been marked as a duplicate of this bug. ***
Comment 3 Cole Robinson 2010-12-01 17:31:32 UTC 
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 Logcher 2011-03-28 21:14:21 UTC 
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 15:58:12 UTC 
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 20:06:59 UTC 
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 23:27:52 UTC 
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 21:08:53 UTC 
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 11:21:57 UTC 
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 09:47:44 UTC 
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 13:13:12 UTC 
    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 06:59:20 UTC 
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.