Bug 816276

Summary:	cloning a VM always sets XML disk driver name to 'raw'
Product:	Red Hat Enterprise Linux 6	Reporter:	Cole Robinson <crobinso>
Component:	python-virtinst	Assignee:	Cole Robinson <crobinso>
Status:	CLOSED WORKSFORME	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	dallan, gkong, jbrouer, jwu, mzhan, rwu, yupzhang, zpeng
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-18 11:40:42 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.