Vitaly Kuznetsov <[email protected]> writes:

> It was found that 'qemu-nbd' is not able to work with some disk images
> exported from Azure. Looking at the 512b footer (which contains VPC
> metadata):
>
> 00000000  63 6f 6e 65 63 74 69 78  00 00 00 02 00 01 00 00  |conectix........|
> 00000010  ff ff ff ff ff ff ff ff  2e c7 9b 96 77 61 00 00  |............wa..|
> 00000020  00 07 00 00 57 69 32 6b  00 00 00 01 40 00 00 00  |....Wi2k....@...|
> 00000030  00 00 00 01 40 00 00 00  28 a2 10 3f 00 00 00 02  |....@...(..?....|
> 00000040  ff ff e7 47 8c 54 df 94  bd 35 71 4c 94 5f e5 44  |...G.T...5qL._.D|
> 00000050  44 53 92 1a 00 00 00 00  00 00 00 00 00 00 00 00  |DS..............|
> 00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>
> we can see that Azure uses a different 'Creator application' --
> 'wa\0\0' (offset 0x1c, likely reads as 'Windows Azure') and QEMU uses this
> field to determine how it can get image size. Apparently, Azure uses 'new'
> method, just like Hyper-V.
>
> Signed-off-by: Vitaly Kuznetsov <[email protected]>
> ---
> Alternatively, we can probably make 'current_size' the default and only use
> CHS for 'vpc '/'qemu'.
> ---
>  block/vpc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/block/vpc.c b/block/vpc.c
> index d95a204612b7..da8662402d00 100644
> --- a/block/vpc.c
> +++ b/block/vpc.c
> @@ -321,6 +321,7 @@ static int vpc_open(BlockDriverState *bs, QDict *options, 
> int flags,
>       *      'qemu'  :  CHS              QEMU (uses disk geometry)
>       *      'qem2'  :  current_size     QEMU (uses current_size)
>       *      'win '  :  current_size     Hyper-V
> +     *      'wa\0\0':  current_size     Azure
>       *      'd2v '  :  current_size     Disk2vhd
>       *      'tap\0' :  current_size     XenServer
>       *      'CTXS'  :  current_size     XenConverter
> @@ -330,6 +331,7 @@ static int vpc_open(BlockDriverState *bs, QDict *options, 
> int flags,
>       *  that have CHS geometry of the maximum size.
>       */
>      use_chs = (!!strncmp(footer->creator_app, "win ", 4) &&
> +               !!strncmp(footer->creator_app, "wa", 4) &&

Stupid me forgot how strncmp() works wrt '\0' bytes, I think we're
better off doing plain memcmp() instead. I'll send v2.

>                 !!strncmp(footer->creator_app, "qem2", 4) &&
>                 !!strncmp(footer->creator_app, "d2v ", 4) &&
>                 !!strncmp(footer->creator_app, "CTXS", 4) &&

-- 
Vitaly


Reply via email to