Bug 803087 - [PATCH] Cloning of a VM fails to clone the disk driver type properly
[PATCH] Cloning of a VM fails to clone the disk driver type properly
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: virtinst (Show other bugs)
unspecified
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Cole Robinson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-13 18:17 EDT by Tuomas Jormola
Modified: 2012-04-02 16:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-02 16:59:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patches CloneDesign to generate the XML required for the <driver type='...'/> element (542 bytes, patch)
2012-03-13 18:17 EDT, Tuomas Jormola
no flags Details | Diff
Hack for virt-clone to work around this problem (828 bytes, patch)
2012-03-13 18:18 EDT, Tuomas Jormola
no flags Details | Diff

  None (edit)
Description Tuomas Jormola 2012-03-13 18:17:44 EDT
Created attachment 569802 [details]
Patches CloneDesign to generate the XML required for the <driver type='...'/> element

Description of problem:

Cloning of a VM doesn't duplicate the driver type of the disk images to be cloned.

Version-Release number of selected component (if applicable):

DistroRelease: Ubuntu 12.04
Package: virtinst 0.600.1-1ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
Architecture: amd64
SourcePackage: virtinst

How reproducible:
Always

Steps to Reproduce:
1. Create a new QEMU/KVM VM called "foo" with a disk in qcow2 format like this

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/foo.img'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>

2. Clone the disk by running
       sudo virt-clone -o foo --auto-clone
   or using virt-manager GUI

Actual results:
The resulting VM foo-clone has the following disk configuration

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/foo-clone.img'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>

The type of the disk is raw, not qcow2 as in the original VM. 

Expected results:

The configuration of the clone should define the disk as the same type as in the original VM, i.e. qcow2 in this case.

Additional info:
The file is properly cloned in the qcow2 format, though, so the issue only affects generation of the clone configuration.

About the patches:

virtinst-0.600.1-generate-cloned-disk-driver-type-xml.diff patches CloneDesign to generate the XML required for the <driver type='...'/> element. Only this patch is needed to fix the described malfunction with virt-manager. After applying this, cloned VMs created with virt-manager will have their configuration correctly cloned.

virtinst-0.600.1-hack-virt-clone-to-support-cloning-of-disk-driver-type.diff is a really ugly hack for virt-clone which makes it work around this problem. Also the previous patch is required so that correct XML is actually generated. This patch overrides the CloneDesign API by directly modifying the list of cloned drives in its CloneDesign object. The problem is that these drives are created in CloneDesign::set_cloned_devices using a fresh instance of VirtualDisk. No info about the original disk is available here, only the filename of the cloned image. Obviously, this isn't enough to supply the driver type to the constructor of VirtualDisk (driverType argument), so this info is effectively lost for the cloned disk. This code should be refactored so that the driver type from the original disk is somehow automatically preserved so the caller (e.g. virt-clone or virt-manager) doesn't have to do anything special. But since I'm not familiar with the code, I don't know where and how to start such refactoring.
Comment 1 Tuomas Jormola 2012-03-13 18:18:25 EDT
Created attachment 569803 [details]
Hack for virt-clone to work around this problem
Comment 2 Tuomas Jormola 2012-03-13 18:31:16 EDT
My initial bug report for Ubuntu regarding this issue
https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/953922
Comment 3 Cole Robinson 2012-04-02 16:59:32 EDT
Thanks for the report. This has actually been fixed independently upstream:

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

Unfortunately those probably won't backport cleanly, in which case I think your hack is sufficient for a distro backport. Closing as UPSTREAM

Note You need to log in before you can comment on or make changes to this bug.