Bug 816276 - cloning a VM always sets XML disk driver name to 'raw'
cloning a VM always sets XML disk driver name to 'raw'
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python-virtinst (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Cole Robinson
Virtualization Bugs
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-25 13:04 EDT by Cole Robinson
Modified: 2012-06-18 07:40 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-18 07:40:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Cole Robinson 2012-04-25 13:04:52 EDT
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 16:36:04 EDT
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 08:32:41 EDT
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 11:00:04 EDT
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 14:48:12 EDT
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 04:15:36 EDT
(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 05:55:31 EDT
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 07:40:42 EDT
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.