Re: [Qemu-block] [PATCH V3] block/vhdx: add check for truncated image files

[Peter Lieven]

Am 04.09.19 um 16:09 schrieb Kevin Wolf:
> Am 03.09.2019 um 15:35 hat Peter Lieven geschrieben:
> > qemu is currently not able to detect truncated vhdx image files.
> > Add a basic check if all allocated blocks are reachable at open and
> > report all errors during bdrv_co_check.
> >
> > Signed-off-by: Peter Lieven <address@hidden>
> > ---
> > V3: - check for bdrv_getlength failure [Kevin]
> >      - use uint32_t for i [Kevin]
> >      - check for BAT entry overflow [Kevin]
> >      - break on !errcnt in second check
> >
> > V2: - add error reporting [Kevin]
> >      - use bdrv_getlength instead of bdrv_get_allocated_file_size [Kevin]
> >      - factor out BAT entry check and add error reporting for region
> >        overlaps
> >      - already check on vhdx_open
> Something still seems to be wrong with this patch:
>
>      213      fail       [15:50:13] [15:50:14]      (last: 2s)    output 
> mismatch (see 213.out.bad)
>      --- /home/kwolf/source/qemu/tests/qemu-iotests/213.out  2019-06-28 
> 14:19:50.065797707 +0200
>      +++ /home/kwolf/source/qemu/tests/qemu-iotests/213.out.bad      2019-09-04 
> 15:50:14.582053976 +0200
>      @@ -46,10 +46,8 @@
>       {"execute": "job-dismiss", "arguments": {"id": "job0"}}
>       {"return": {}}
>
>      -image: TEST_IMG
>      -file format: IMGFMT
>      -virtual size: 32 MiB (33554432 bytes)
>      -cluster_size: 268435456
>      +qemu-img: VHDX BAT entry 0 offset points after end of file. Image has 
> probably been truncated.
>      +qemu-img: Could not open 'TEST_IMG': Could not open 'TEST_IMG': Invalid 
> argument
>
>       === Invalid BlockdevRef ===
>
> I can reproduce this manually with the following qemu-img invocations.
> It seems all three options must be given to reproduce the error:
>
>      $ ./qemu-img create -f vhdx -o 
> block_size=268435456,subformat=fixed,block_state_zero=off /tmp/test.vhdx 32M
>      Formatting '/tmp/test.vhdx', fmt=vhdx size=33554432 log_size=1048576 
> block_size=268435456 subformat=fixed block_state_zero=off
>      $ ./qemu-img info /tmp/test.vhdx
>      qemu-img: VHDX BAT entry 0 offset points after end of file. Image has 
> probably been truncated.
>      qemu-img: Could not open '/tmp/test.vhdx': Could not open 
> '/tmp/test.vhdx': Invalid argument
>
> If I add the offsets to the error message (would probably nice to have),
> I get:
>
>      qemu-img: VHDX BAT entry 0 offset 8388608 points after end of file 
> (41943040). Image has probably been truncated.
>
> So it seems that the file is large enough to hold 32M + metadata, but we
> don't increase the file size to hold a full block (256M). Is this a
> problem in the way we create images or are partial blocks at the end
> expected?
>
> Kevin


A short look into the VHDX spec [1] seems to suggest that a VHDX File can only 
grow in Block increments.

See page 8 in the definition of blocks: "Allocation of new space for a virtual 
hard disk that supports dynamic growth

of the virtual hard disk file is done in fixes size units defined as blocks."


Peter


[1] https://www.microsoft.com/en-us/download/confirmation.aspx?id=34750




--

Mit freundlichen Grüßen

Peter Lieven

...........................................................

  KAMP Netzwerkdienste GmbH
  Vestische Str. 89-91 | 46117 Oberhausen
  Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
  address@hidden | http://www.kamp.de

  Geschäftsführer: Heiner Lante | Michael Lante
  Amtsgericht Duisburg | HRB Nr. 12154
  USt-Id-Nr.: DE 120607556

...........................................................