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 816276 - cloning a VM always sets XML disk driver name to 'raw'
Summary: cloning a VM always sets XML disk driver name to 'raw'
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python-virtinst
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Cole Robinson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-25 17:04 UTC by Cole Robinson
Modified: 2012-06-18 11:40 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-18 11:40:42 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Cole Robinson 2012-04-25 17:04:52 UTC 
Using virt-clone (or virt-manager) to clone a VM with a qcow2 image results in unbootable XML, since we aren't copying over the XML disk driver name.

Upstream fix here:

http://git.fedorahosted.org/git?p=python-virtinst.git;a=commit;h=f0195e95d57deda83daed5231582ca86bde519ae
http://git.fedorahosted.org/git?p=python-virtinst.git;a=commit;h=c9ae2ac4668213c03614842d92327737a25cf9ec

Though it probably won't backport cleanly.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=795400
Comment 2 Cole Robinson 2012-05-02 20:36:04 UTC 
Hmm, actually I thought RHEL6 was affected by this, but I think it was a regression in virtinst-0.600.1 and later. So turns out this works in RHEL6. Closing this
Comment 3 Jesper Brouer 2012-06-08 12:32:41 UTC 
Hi Cole,

I'm experiencing this issue on RHEL 6.3 beta.

Work-around: (for others also hitting this)

 1. Edit the details of the VM
 2. Choose: "VirtIO Disk 1"
 3. Select "Advanced options"
 4. Change "Storage format" manually from "raw" to "qcow2"
 5. Press apply
 Then the cloned system is able to boot.

Software versions on my system:
 python-virtinst-0.600.0-8.el6.noarch
 libvirt-0.9.10-11.el6.x86_64
 virt-manager-0.9.0-11.el6.x86_64
Comment 5 Cole Robinson 2012-06-17 15:00:04 UTC 
Hi Jesper, please provide the full virt-clone command line, and the output of that command with the --debug flag.
Comment 6 Cole Robinson 2012-06-17 18:48:12 UTC 
Whoops, set wrong needinfo.

Jesper, please provide the full virt-clone command line, and the output of that command with the --debug flag.
Comment 7 Jesper Brouer 2012-06-18 08:15:36 UTC 
(In reply to comment #6)
> 
> Jesper, please provide the full virt-clone command line, and the output of
> that command with the --debug flag.

I'm using virt-manager to clone, so I don't know the virt-clone command line parameters...
Comment 8 Jesper Brouer 2012-06-18 09:55:31 UTC 
Hi Cole,

I just tried to reproduce, but cannot. This time it works, and the qcow2 disk gets the the correct type in the clone.

The software versions are the same:
 (rpm -q python-virtinst libvirt virt-manager)
 python-virtinst-0.600.0-8.el6.noarch
 libvirt-0.9.10-11.el6.x86_64
 virt-manager-0.9.0-11.el6.x86_64

Very strange. The only big difference is that I have rebooted the physical server. I'm thinking perhaps I was running a different version of libvirtd, than the installed one, but not sure it would make any difference in this case.

Well, feel free to close the case, and I cannot reproduce any longer...

--Jesper Brouer
Comment 9 Cole Robinson 2012-06-18 11:40:42 UTC 
Okay, closing. Jesper, if you reproduce in the future, please provide the output of virt-manager --debug when reproducing.
Note You need to log in before you can comment on or make changes to this bug.