Red Hat Bugzilla – Bug 816276
cloning a VM always sets XML disk driver name to 'raw'
Last modified: 2012-06-18 07:40:42 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:
Though it probably won't backport cleanly.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=795400
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
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:
Hi Jesper, please provide the full virt-clone command line, and the output of that command with the --debug flag.
Whoops, set wrong needinfo.
Jesper, please provide the full virt-clone command line, and the output of that command with the --debug flag.
(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...
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)
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...
Okay, closing. Jesper, if you reproduce in the future, please provide the output of virt-manager --debug when reproducing.