Isolated convert command:
$ sudo qemu-img convert -f qcow2 -O qcow2 -o compat=1.1,lazy_refcounts
/var/lib/uvtool/libvirt/images/focal-nvdimm.qcow
/var/lib/uvtool/libvirt/images/focal-nvdimm-clone.qcow
qemu-img: Could not open '/var/lib/uvtool/libvirt/images/focal-nvdimm.qcow':
Failed to get shared "write" lock
Is another process using the image
[/var/lib/uvtool/libvirt/images/focal-nvdimm.qcow]?
With --force-share added it works
Called from virt-clone via libvirt by:
virStorageVolCreateXMLFrom:1555 : pool=0x7f9aec00e590, xmlDesc=<volume>
<name>focal-nvdimm-clone.qcow</name>
<capacity>10737418240</capacity>
<allocation>9155248128</allocation>
<target>
<format type="qcow2"/>
<features>
<lazy_refcounts/>
</features>
</target>
</volume>
, clonevol=0x7f9aec00d9d0, flags=0x0
2020-04-21 10:09:05.605+0000: 817407
Formerly identified by
virStorageVolGetXMLDesc:2032 : vol=0x7f9aec00d9d0, flags=0x0
The backend is type dependent, in this case it is a qcow file, so
virStorageBackendForType(def->type)
will give us:
virStorageBackendDiskBuildVolFrom
Then virStorageBackendGetBuildVolFromFunction delivers
storageBackendCreateQemuImg
Finally storageBackendDoCreateQemuImg will call
virStorageBackendCreateQemuImgCmdFromVol to get the right command that is then
executed.
In our case the cmd above.
It still is a matter of data integrity.
I'm unsure if adding --force-share to virStorageBackendCreateQemuImgCmdFromVol
will not create cases where this causes (potentially silent) data corruption.
The problem is that the man page still is correct for some types, e.g.
raw disk files or probably even things like LVM or such.
I wonder if we should just ask to update the man page that this depends on
storage type (in which case this would be a rather low prio bug).
Opinions?
** Changed in: virt-manager (Ubuntu)
Status: New => Triaged
** Changed in: virt-manager (Ubuntu)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1873887
Title:
virt-clone fails on a suspended (paused) guest, whereas documentation
claims the clone should be successful.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1873887/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
