Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
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:


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.