[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] "qemu-img: File contains external, encrypted or compres
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] "qemu-img: File contains external, encrypted or compressed clusters." |
Date: |
Thu, 28 Mar 2019 17:18:23 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 |
On 3/28/19 7:30 AM, Eric Blake wrote:
> On 3/28/19 5:59 AM, Richard W.M. Jones wrote:
>> This error message is confusing and looks wrong to me:
>
> Confusing, but intentional design decision at the time (that said, I
> would also welcome an improvement).
>
>>
>> $ ./nbdkit -U - data data="1" size=1M --run 'qemu-img map $nbd'
>> Offset Length Mapped to File
>> qemu-img: File contains external, encrypted or compressed clusters.
>
> It's due to the fact that the human output WANTS to fill in the "mapped
> to" column, but can't, because there is no "File" that you can open and
> read from the "Mapped to" offset of that file to see the same thing as
> the guest would see at "Offset".
>
> Perhaps if we tweaked the output to just say:
>
> $ qemu-img map file
> Offset Length Mapped to File
> 0 0x1000 N/A
> (try again with --output=json for full details)
> $
>
That's still a worthwhile idea for 4.1 for compressed/encrypted images.
But for NBD, I can do one better; I'll post a patch for 4.0 that makes
nbd behave more like file-posix - in short, the protocol level should be
returning BDRV_BLOCK_OFFSET_VALID in addition to everything else it
learns from the server, improving the output to:
Offset Length Mapped to File
0 0x1ff 0 nbd://localhost:10809
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature