[Qemu-devel] [PATCH 0/2] block: Fix qemu-img creating overlay when guest running

[Qemu-devel] [PATCH 0/2] block: Fix qemu-img creating overlay when guest running

[Fam Zheng]

Shared write lock is not strictly necessary for creating the overlay image, if
all what we want is to probe the size.

Fam Zheng (2):
  block: Open backing image in force share mode for size probe
  iotests: Test creating overlay when guest running

 block.c                    | 3 ++-
 tests/qemu-iotests/153     | 4 ++++
 tests/qemu-iotests/153.out | 3 +++
 3 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.14.3

[Qemu-devel] [PATCH 1/2] block: Open backing image in force share mode for size probe

[Fam Zheng]

Management tools create overlays of running guests with qemu-img:

  $ qemu-img create -b /image/in/use.qcow2 -f qcow2 /overlay/image.qcow2

but this doesn't work anymore due to image locking:

    qemu-img: /overlay/image.qcow2: Failed to get shared "write" lock
    Is another process using the image?
    Could not open backing image to determine size.
Use the force share option to allow this use case again.

Cc: qemu-stable@nongnu.org
Signed-off-by: Fam Zheng <famz@redhat.com>
---
 block.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/block.c b/block.c
index 9a1a0d1e73..f236431da1 100644
--- a/block.c
+++ b/block.c
@@ -4593,10 +4593,11 @@ void bdrv_img_create(const char *filename, const char *fmt,
         back_flags = flags;
         back_flags &= ~(BDRV_O_RDWR | BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING);
 
+        backing_options = qdict_new();
         if (backing_fmt) {
-            backing_options = qdict_new();
             qdict_put_str(backing_options, "driver", backing_fmt);
         }
+        qdict_put_bool(backing_options, BDRV_OPT_FORCE_SHARE, true);
 
         bs = bdrv_open(full_backing, NULL, backing_options, back_flags,
                        &local_err);
-- 
2.14.3

Re: [Qemu-devel] [PATCH 1/2] block: Open backing image in force share mode for size probe

[Kevin Wolf]

Am 15.12.2017 um 09:04 hat Fam Zheng geschrieben:
> Management tools create overlays of running guests with qemu-img:
> 
>   $ qemu-img create -b /image/in/use.qcow2 -f qcow2 /overlay/image.qcow2
> 
> but this doesn't work anymore due to image locking:
> 
>     qemu-img: /overlay/image.qcow2: Failed to get shared "write" lock
>     Is another process using the image?
>     Could not open backing image to determine size.
> Use the force share option to allow this use case again.
> 
> Cc: qemu-stable@nongnu.org
> Signed-off-by: Fam Zheng <famz@redhat.com>

Thanks, applied this patch to the block branch. Please resend a fixed
version of the test case.

Kevin

[Qemu-devel] [PATCH 2/2] iotests: Test creating overlay when guest running

[Fam Zheng]

Signed-off-by: Fam Zheng <famz@redhat.com>
---
 tests/qemu-iotests/153     | 4 ++++
 tests/qemu-iotests/153.out | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/tests/qemu-iotests/153 b/tests/qemu-iotests/153
index fa25eb24bd..22cb9c69a7 100755
--- a/tests/qemu-iotests/153
+++ b/tests/qemu-iotests/153
@@ -32,6 +32,7 @@ _cleanup()
 {
     _cleanup_test_img
     rm -f "${TEST_IMG}.base"
+    rm -f "${TEST_IMG}.overlay"
     rm -f "${TEST_IMG}.convert"
     rm -f "${TEST_IMG}.a"
     rm -f "${TEST_IMG}.b"
@@ -218,6 +219,9 @@ _send_qemu_cmd $QEMU_HANDLE \
 
 _run_cmd $QEMU_IO "${TEST_IMG}" -c 'write 0 512'
 
+echo "Creating overlay with qemu-img when the guest is running should be allowed"
+_run_cmd $QEMU_IMG create -f $IMGFMT -b "${TEST_IMG}" "${TEST_IMG}.overlay"
+
 echo "Closing the other"
 _send_qemu_cmd $QEMU_HANDLE \
     "{ 'execute': 'human-monitor-command',
diff --git a/tests/qemu-iotests/153.out b/tests/qemu-iotests/153.out
index 5b917b177c..8131180c49 100644
--- a/tests/qemu-iotests/153.out
+++ b/tests/qemu-iotests/153.out
@@ -390,6 +390,9 @@ _qemu_img_wrapper info TEST_DIR/t.qcow2
 _qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
 can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
 Is another process using the image?
+Creating overlay with qemu-img when the guest is running should be allowed
+
+_qemu_img_wrapper create -f qcow2 -b TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.overlay
 Closing the other
 
 _qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
-- 
2.14.3

Re: [Qemu-devel] [PATCH 2/2] iotests: Test creating overlay when guest running

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

On 12/15/2017 02:04 AM, Fam Zheng wrote:
> Signed-off-by: Fam Zheng <famz@redhat.com>
> ---
>  tests/qemu-iotests/153     | 4 ++++
>  tests/qemu-iotests/153.out | 3 +++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/tests/qemu-iotests/153 b/tests/qemu-iotests/153
> index fa25eb24bd..22cb9c69a7 100755
> --- a/tests/qemu-iotests/153
> +++ b/tests/qemu-iotests/153
> @@ -32,6 +32,7 @@ _cleanup()
>  {
>      _cleanup_test_img
>      rm -f "${TEST_IMG}.base"
> +    rm -f "${TEST_IMG}.overlay"
>      rm -f "${TEST_IMG}.convert"

Conflicts with the series to clean up iotests to run in a per-test
directory with automatic cleanup, but the resolution is obvious.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: [Qemu-devel] [PATCH 2/2] iotests: Test creating overlay when guest running

[Kevin Wolf]

Am 15.12.2017 um 09:04 hat Fam Zheng geschrieben:
> Signed-off-by: Fam Zheng <famz@redhat.com>

The updated test case passes even without your fix. I can reproduce the
problem manually and verify that patch 1 fixes it, but the test case
seems ineffective.

And having a closer look at the test, this is because the running VM
opened its images read-only.

Kevin

Re: [Qemu-devel] [PATCH 0/2] block: Fix qemu-img creating overlay when guest running

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On 12/15/2017 02:04 AM, Fam Zheng wrote:
> Shared write lock is not strictly necessary for creating the overlay image, if
> all what we want is to probe the size.

Theoretically, the size could be changing due to a resize operation.
But realistically, even if that happens, we will (hopefully) see either
the old size or the new size atomically (that is, I seriously doubt the
size information is split across multiple sectors of the in-use image to
the point that we could shard the read).

Series:
Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]