Bug 647174
| Summary: | RHEL6: virt-clone should remove old udev rules when changing MAC address | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Chris Tatman <ctatman> |
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.0 | CC: | berrange, crobinso, dallan, eparis, everett.bennett, gasmith, jcm, jzheng, leiwang, maurizio.antillon, myllynen, pcao, qguan, qwan, renich, rhbugzilla, rhbugzi, rjones, sputhenp, virt-maint, xen-maint |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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 06:59:20 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 524269, 719879 | ||
| Bug Blocks: | 727267, 747123, 747667, 756082 | ||
|
Description
Chris Tatman
2010-10-27 13:33:15 UTC
*** 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 |