Package: virtinst
Version: 0.600.1-3+deb7u1
Severity: normal
Tags: patch
Cloning into existing storage volumes is supposedly not supported.
#706196 marks this as a regression and #745873 as a wishlist item. In
old-stable it worked, so I feel that calling it a regression is correct.
When looking at what spit out this error, it seemed to me that the check
is too simplistic and I can actually clone into existing storage
volumes, if referenced differently:
virsh pool-dumpxml vg01
<pool type='logical'>
<name>vg01</name>
<uuid>2ae3ae6c-7aa0-f7db-f771-183406d653ee</uuid>
<capacity unit='bytes'>560598089728</capacity>
<allocation unit='bytes'>157655498752</allocation>
<available unit='bytes'>402942590976</available>
<source>
<device path='/dev/block/104:3'/>
<name>vg01</name>
<format type='lvm2'/>
</source>
<target>
<path>/dev/vg01</path>
<permissions>
<mode>0700</mode>
<owner>4294967295</owner>
<group>4294967295</group>
</permissions>
</target>
</pool>
root@cheetah:/tmp/tmp.oCzq69YIdx# virt-clone -o leap-baseimage -f
/dev/vg01/review-root -n test
ERROR Clone onto existing storage volume is not supported:
'/dev/vg01/review-root'
root@cheetah:/tmp/tmp.oCzq69YIdx# virt-clone -o leap-baseimage -f
/dev/mapper/vg01-review--root -n test
Cloning vg01-leap--baseimage
| 10 GB 00:05
Clone 'test' created successfully.
I liked that success, but in both cases it was actually writing to the
same place:
root@cheetah:/usr/share/pyshared/virtinst# readlink
/dev/mapper/vg01-review--root
../dm-0
root@cheetah:/usr/share/pyshared/virtinst# readlink /dev/vg01/review-root
../dm-0
Why this happens? The answer is in CloneManager.py:
474 if clone_disk.vol_object:
475 # XXX We could do this with vol upload I think
476 raise RuntimeError(
477 _("Clone onto existing storage volume is not "
478 "supported: '%s'") % clone_disk.path)
For both me and #706196 this is sort of fixed upstream when it are local
storage pools:
https://git.fedorahosted.org/cgit/virt-manager.git/tree/virtinst/CloneManager.py?id=v0.10.0
Virt-inst is now merged in virt-manager. With attached patch (which
comes from upstream) I'm happy. I don't know if this patch should get
into backports or the other 2 bugs can be closed because of this and/or
upstream changes, an explanation of bug-flow would be welcome.
-- System Information:
Debian Release: 7.5
APT prefers stable
APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages virtinst depends on:
ii python 2.7.3-4+deb7u1
ii python-libvirt 0.9.12.3-1
ii python-libxml2 2.8.0+dfsg1-7+nmu3
ii python-support 1.0.15
ii python-urlgrabber 3.9.1-4
Versions of packages virtinst recommends:
ii qemu 1.1.2+dfsg-6a+deb7u2
ii virt-viewer 0.5.3-1
virtinst suggests no packages.
-- no debconf information
474,475c474,487
< if clone_disk.vol_object:
< # XXX We could do this with vol upload I think
---
> if clone_disk.vol_object:
> # XXX We could always do this with vol upload?
>
> # Special case: non remote cloning of a guest using
> # managed block devices: fall back to local cloning if
> # we have permissions to do so. This validation check
> # caused a few bug reports in a short period of time,
> # so must be a common case.
> if (clone_disk.is_remote() or
> clone_disk.type != clone_disk.TYPE_BLOCK or
> not orig_disk.path or
> not os.access(orig_disk.path, os.R_OK) or
> not clone_disk.path or
> not os.access(clone_disk.path, os.W_OK)):
478c490
< "supported: '%s'") % clone_disk.path)
---
> "currently supported: '%s'") % clone_disk.path)
