[libvirt] [PATCH] qemu: blockcopy: Forbid using persistent bitmap granularity with raw vols

qemu returns error but only in the event after the block job actually starts. Reject it upfront for a better error message. Instead of: $ virsh blockcopy vm hdc /tmp/raw.img --granularity 4096 --verbose --wait error: Block Copy unexpectedly failed You will now get: $ virsh blockcopy vm hdc /tmp/raw.img --granularity 4096 --verbose --wait error: unsupported configuration: granularity can't be used with target volume format Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1233115 --- src/qemu/qemu_driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index c1373de..f570879 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -16671,6 +16671,16 @@ qemuDomainBlockCopyCommon(virDomainObjPtr vm, goto endjob; } + /* blacklist granularity with some known-bad formats */ + if (granularity && + (mirror->format == VIR_STORAGE_FILE_RAW || + (mirror->format <= VIR_STORAGE_FILE_NONE && + disk->src->format == VIR_STORAGE_FILE_RAW))) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("granularity can't be used with target volume format")); + goto endjob; + } + /* Prepare the destination file. */ /* XXX Allow non-file mirror destinations */ if (!virStorageSourceIsLocalStorage(mirror)) { -- 2.4.1

On 06/24/2015 03:11 PM, Peter Krempa wrote:
qemu returns error but only in the event after the block job actually starts. Reject it upfront for a better error message.
Instead of: $ virsh blockcopy vm hdc /tmp/raw.img --granularity 4096 --verbose --wait error: Block Copy unexpectedly failed
You will now get: $ virsh blockcopy vm hdc /tmp/raw.img --granularity 4096 --verbose --wait error: unsupported configuration: granularity can't be used with target volume format
This can't avoid the cases that the source file has a raw format file as backing file.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1233115 --- src/qemu/qemu_driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index c1373de..f570879 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -16671,6 +16671,16 @@ qemuDomainBlockCopyCommon(virDomainObjPtr vm, goto endjob; }
+ /* blacklist granularity with some known-bad formats */ + if (granularity && + (mirror->format == VIR_STORAGE_FILE_RAW || + (mirror->format <= VIR_STORAGE_FILE_NONE && + disk->src->format == VIR_STORAGE_FILE_RAW))) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("granularity can't be used with target volume format")); + goto endjob; + } + /* Prepare the destination file. */ /* XXX Allow non-file mirror destinations */ if (!virStorageSourceIsLocalStorage(mirror)) {
-- Regards shyu

On Wed, Jun 24, 2015 at 16:48:16 +0800, Shanzhi Yu wrote:
On 06/24/2015 03:11 PM, Peter Krempa wrote:
qemu returns error but only in the event after the block job actually starts. Reject it upfront for a better error message.
Instead of: $ virsh blockcopy vm hdc /tmp/raw.img --granularity 4096 --verbose --wait error: Block Copy unexpectedly failed
You will now get: $ virsh blockcopy vm hdc /tmp/raw.img --granularity 4096 --verbose --wait error: unsupported configuration: granularity can't be used with target volume format
This can't avoid the cases that the source file has a raw format file as backing file.
AFAIK if the active image (top layer) is a qcow2, then the destination is also created as a qcow2 and thus the persistent bitmap granularity should work just fine. Peter

On 06/24/2015 05:33 PM, Peter Krempa wrote:
On Wed, Jun 24, 2015 at 16:48:16 +0800, Shanzhi Yu wrote:
On 06/24/2015 03:11 PM, Peter Krempa wrote:
qemu returns error but only in the event after the block job actually starts. Reject it upfront for a better error message.
Instead of: $ virsh blockcopy vm hdc /tmp/raw.img --granularity 4096 --verbose --wait error: Block Copy unexpectedly failed
You will now get: $ virsh blockcopy vm hdc /tmp/raw.img --granularity 4096 --verbose --wait error: unsupported configuration: granularity can't be used with target volume format This can't avoid the cases that the source file has a raw format file as backing file.
AFAIK if the active image (top layer) is a qcow2, then the destination is also created as a qcow2 and thus the persistent bitmap granularity should work just fine.
Consider I have a guest as below: # virsh dumpxml r7-raw|grep disk -A 8 <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/rhel7-raw.s1'/> <backingStore type='file' index='1'> <format type='raw'/> <source file='/var/lib/libvirt/images/rhel7-raw.img'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> case I: # virsh blockcopy r7-raw vda /var/lib/libvirt/images/rhel7-raw.s1.cp --verbose --wait --granularity 4096 error: Block Copy unexpectedly failed case II: # virsh blockcopy r7-raw vda /var/lib/libvirt/images/rhel7-raw.s1.cp --verbose --wait --granularity 4096 --shallow Block Copy: [ 0 %]error: Block Copy unexpectedly failed
Peter
-- Regards shyu
participants (2)
-
Peter Krempa
-
Shanzhi Yu