Your message dated Mon, 30 Nov 2020 08:18:24 +0100
with message-id <107118049.nniJfEyVGO@thyrus>
and subject line Re: Bug#748120: [Pkg-libvirt-maintainers] Bug#748120: Improper
device checking with virt-clone on LVM
has caused the Debian Bug report #748120,
regarding Improper device checking with virt-clone on LVM
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
748120: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748120
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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)
--- End Message ---
--- Begin Message ---
Source: virt-manager
Source-Version: 1:0.10.0-1
In data giovedì 9 ottobre 2014 11:47:18 CET, intrigeri ha scritto:
> Guido Günther wrote (14 May 2014 15:57:27 GMT) :
> > On Wed, May 14, 2014 at 03:52:47PM +0200, Kwadronaut-debian wrote:
> >> 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.
>
> Can you please confirm that the problem is gone with the package
> (based on upstream 1.0.1) that's currently in testing/sid?
Indeed it was fixed already before the merge of python-virtinst into
virt-manager.
> >> 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.
>
> > Backports would mean backporting the whole virt-manager 1.0 so we can
> > only onsider a update via a point update. This would mean we need to
> > fix it in unstable first which we should do by bringing virt-manager
> > 1.0 into sid (currently only in experimental). I try to find the time
> > to finally package 1.0 (instead of a git snapshot).
>
> That's now been done, not sure what's the next thing to do here.
Let's close this, then.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
