[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v2] vmdk: Set vmdk parent backing_format to vmdk

From: Sam
Subject: Re: [Qemu-block] [PATCH v2] vmdk: Set vmdk parent backing_format to vmdk
Date: Sat, 4 May 2019 15:43:25 +0300

Thanks Thomas, Thanks Max

So how do you want to proceed?

Apply Max’s RFC from here (http://lists.nongnu.org/archive/html/qemu-block/2019-04/msg00442.html) and add the commit id which is stable now?
Or should I resubmit my fix (which is very similar to what Max did) without the original change?


On 3 May 2019, at 17:32, Max Reitz <address@hidden> wrote:

On 03.05.19 13:34, Thomas Huth wrote:
Hi Sam,

On 02/05/2019 15.08, Sam Eiderman wrote:
Commit b69864e ("vmdk: Support version=3 in VMDK descriptor files")
fixed the probe function to correctly guess vmdk descriptors with

This solves the issue where vmdk snapshot with parent vmdk descriptor
containing "version=3" would be treated as raw instead vmdk.

In the future case where a new vmdk version is introduced, we will again
experience this issue, even if the user will provide "-f vmdk" it will
only apply to the tip image and not to the underlying "misprobed" parent

The code in vmdk.c already assumes that the backing file of vmdk must be
vmdk (see vmdk_is_cid_valid which returns 0 if backing file is not

So let's make it official by supplying the backing_format as vmdk.

Reviewed-by: Mark Kanda <address@hidden>
Reviewed-By: Liran Alon <address@hidden>
Reviewed-by: Arbel Moshe <address@hidden>
Signed-off-by: Shmuel Eiderman <address@hidden>
block/vmdk.c           | 2 ++
tests/qemu-iotests/110 | 6 +++---
tests/qemu-iotests/126 | 4 ++--
3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/block/vmdk.c b/block/vmdk.c
index 8dec6ef767..de8cb859f8 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -397,6 +397,8 @@ static int vmdk_parent_open(BlockDriverState *bs)
        pstrcpy(bs->auto_backing_file, end_name - p_name + 1, p_name);
        pstrcpy(bs->backing_file, sizeof(bs->backing_file),
+        pstrcpy(bs->backing_format, sizeof(bs->backing_format),
+                "vmdk");

Your patch with this change has already been merged into the QEMU master

diff --git a/tests/qemu-iotests/110 b/tests/qemu-iotests/110
index fad672c1ae..982569dbc5 100755
--- a/tests/qemu-iotests/110
+++ b/tests/qemu-iotests/110
@@ -54,7 +54,7 @@ _make_test_img -b "$TEST_IMG_REL.base" 64M
# qemu should be able to reconstruct the filename, so relative backing names
# should work
TEST_IMG="json:{'driver':'$IMGFMT','file':{'driver':'file','filename':'$TEST_IMG'}}" \
-    _img_info | _filter_img_info
+    _img_info | _filter_img_info | grep -v "backing file format"

echo '=== Non-reconstructable filename ==='
@@ -78,7 +78,7 @@ TEST_IMG="json:{
-}" _img_info | _filter_img_info
+}" _img_info | _filter_img_info | grep -v "backing file format"

echo '=== Backing name is always relative to the backed image ==='
@@ -110,7 +110,7 @@ TEST_IMG="json:{
-}" _img_info | _filter_img_info
+}" _img_info | _filter_img_info | grep -v "backing file format"

# success, all done
diff --git a/tests/qemu-iotests/126 b/tests/qemu-iotests/126
index 96dc048d59..1f7618c8a5 100755
--- a/tests/qemu-iotests/126
+++ b/tests/qemu-iotests/126
@@ -63,7 +63,7 @@ TEST_IMG=$BASE_IMG _make_test_img 64M
TEST_IMG=$TOP_IMG _make_test_img -b ./image:base.$IMGFMT

# The default cluster size depends on the image format
-TEST_IMG=$TOP_IMG _img_info | grep -v 'cluster_size'
+TEST_IMG=$TOP_IMG _img_info | grep -v 'cluster_size\|backing file format'

_rm_test_img "$BASE_IMG"
_rm_test_img "$TOP_IMG"
@@ -79,7 +79,7 @@ TOP_IMG="file:image:top.$IMGFMT"
TEST_IMG=$BASE_IMG _make_test_img 64M
TEST_IMG=$TOP_IMG _make_test_img -b "$BASE_IMG"

-TEST_IMG=$TOP_IMG _img_info | grep -v 'cluster_size'
+TEST_IMG=$TOP_IMG _img_info | grep -v 'cluster_size\|backing file format'

_rm_test_img "$BASE_IMG"
_rm_test_img "image:top.$IMGFMT"

... so please just send a patch with these fixes!

I already did, it's here:



reply via email to

[Prev in Thread] Current Thread [Next in Thread]