qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-block] [PATCH 7/7] iotests: Disable 126 for some


From: John Snow
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 7/7] iotests: Disable 126 for some vmdk subformats
Date: Mon, 12 Aug 2019 17:33:20 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0


On 7/25/19 11:57 AM, Max Reitz wrote:
> Several vmdk subformats do not work with iotest 126, so disable them.
> 
> (twoGbMaxExtentSparse actually should work, but fixing that is a bit
> difficult.  The problem is that the vmdk descriptor file will contain a
> referenc to "image:base.vmdk", which the block layer cannot open because

reference

> it does not know the protocol "image".  This is not trivial to solve,
> because I suppose real protocols like "http://"; should be supported.
> Making vmdk treat all paths with a potential protocol prefix that the
> block layer does not recognize as plain files seems a bit weird,
> though.  Ignoring this problem does not seem too bad.)
> 
> Signed-off-by: Max Reitz <address@hidden>
> ---
>  tests/qemu-iotests/126 | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tests/qemu-iotests/126 b/tests/qemu-iotests/126
> index 9b0dcf9255..8e55d7c843 100755
> --- a/tests/qemu-iotests/126
> +++ b/tests/qemu-iotests/126
> @@ -33,6 +33,12 @@ status=1   # failure is the default!
>  
>  # Needs backing file support
>  _supported_fmt qcow qcow2 qed vmdk
> +# (1) Flat vmdk images do not support backing files
> +# (2) Split vmdk images simply fail this test right now.  Fixing that
> +#     is left for another day.

Which one? :)

> +_unsupported_imgopts "subformat=monolithicFlat" \
> +                     "subformat=twoGbMaxExtentFlat" \
> +                     "subformat=twoGbMaxExtentSparse"
>  # This is the default protocol (and we want to test the difference between
>  # colons which separate a protocol prefix from the rest and colons which are
>  # just part of the filename, so we cannot test protocols which require a 
> prefix)
> 

What exactly fails? Does the VMDK driver see `image:` and think it's a
special filename it needs to handle and fails to do so?





reply via email to

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