Xen devel - Feb 2013 - why are qemu-img and vhd-util created files incompatible?

I was wondering if someone can shed some light on why vhd files
created with qemu-img don''t really work right with vhd-util and
consequentially blktap in general.  To validate the incompatiblity its
simple enough to do

qemu-img create -f vpc test.vhd 40g
vhd-util snapshot -n child.vhd -p test.vhd

Which will show the below and then the headers don''t display the BATMAP
summary:

primary footer invalid: creation time in future
test.vhd appears invalid; dumping metadata
Failed to open test.vhd: -22

Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will give
you the same 22 error.

I was going to start researching this with the eventual goal of
changing qemu-img, but I thought I''d ask the experts first.

Thanks,
Darren

Darren Shepherd writes ("[Xen-devel] why are qemu-img and vhd-util created
files incompatible?"):
> I was wondering if someone can shed some light on why vhd files
> created with qemu-img don''t really work right with vhd-util and
> consequentially blktap in general.  To validate the incompatiblity its
> simple enough to do
> 
> qemu-img create -f vpc test.vhd 40g
> vhd-util snapshot -n child.vhd -p test.vhd
...
> Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will
give
> you the same 22 error.
> 
> I was going to start researching this with the eventual goal of
> changing qemu-img, but I thought I''d ask the experts first.
I''m afraid there aren''t many experts here on the vhd code in
the
xen-unstable tree.  It''s possible that the qemu-img built from
qemu-xen-traditional "qemu-img-xen" might be more compatible.

Please do let us know what you discover.

Thanks,
Ian.

On Sun, Feb 17, 2013 at 2:30 PM, Darren Shepherd
<darren.s.shepherd@gmail.com> wrote:
> I was wondering if someone can shed some light on why vhd files
> created with qemu-img don''t really work right with vhd-util and
> consequentially blktap in general.  To validate the incompatiblity its
> simple enough to do
>
> qemu-img create -f vpc test.vhd 40g
> vhd-util snapshot -n child.vhd -p test.vhd
>
> Which will show the below and then the headers don''t display the
BATMAP summary:
>
> primary footer invalid: creation time in future
This is due to a bug in the blktap2 code which uses local time instead
of UTC (which is mandated by the VHD specs). I fixed it recently in
the Citrix fork of blktap
(https://github.com/xen-org/blktap/commit/a79ac2c05f97c2384bbf981419f329f184dc646a),
but unfortunately these two forks aren''t really kept in sync.
> test.vhd appears invalid; dumping metadata
> Failed to open test.vhd: -22
>
> Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will
give
> you the same 22 error.
>
> I was going to start researching this with the eventual goal of
> changing qemu-img, but I thought I''d ask the experts first.
>
> Thanks,
> Darren
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Thanks, I''ll try out that patch.  I''m using the CentOS 6
bundle of Xen
which pulls in a lot of the newer blktap code.  Do you know if that is
the only thing that prevents snapshots from working?  I have seen
people work around the time issue with just using the faketime
preload, but I think there is something beyond the timestamp that is
incompatible.

Thanks,
Darren

On Tue, Feb 19, 2013 at 4:40 PM, Andrei Lifchits
<andrei.lifchits@citrix.com> wrote:
> On Sun, Feb 17, 2013 at 2:30 PM, Darren Shepherd
> <darren.s.shepherd@gmail.com> wrote:
>> I was wondering if someone can shed some light on why vhd files
>> created with qemu-img don''t really work right with vhd-util
and
>> consequentially blktap in general.  To validate the incompatiblity its
>> simple enough to do
>>
>> qemu-img create -f vpc test.vhd 40g
>> vhd-util snapshot -n child.vhd -p test.vhd
>>
>> Which will show the below and then the headers don''t display
the BATMAP summary:
>>
>> primary footer invalid: creation time in future
>
> This is due to a bug in the blktap2 code which uses local time instead
> of UTC (which is mandated by the VHD specs). I fixed it recently in
> the Citrix fork of blktap
>
(https://github.com/xen-org/blktap/commit/a79ac2c05f97c2384bbf981419f329f184dc646a),
> but unfortunately these two forks aren''t really kept in sync.
>
>> test.vhd appears invalid; dumping metadata
>> Failed to open test.vhd: -22
>>
>> Additionally "vhd-util snapshot -n child.vhd -p test.vhd"
will give
>> you the same 22 error.
>>
>> I was going to start researching this with the eventual goal of
>> changing qemu-img, but I thought I''d ask the experts first.
>>
>> Thanks,
>> Darren
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

On Wed, Feb 20, 2013 at 3:52 PM, Darren Shepherd
<darren.s.shepherd@gmail.com> wrote:
> Thanks, I''ll try out that patch.  I''m using the CentOS 6
bundle of Xen
> which pulls in a lot of the newer blktap code.  Do you know if that is
> the only thing that prevents snapshots from working?
I don''t, sorry: I''ve never really used OSS Xen until now.
> people work around the time issue with just using the faketime
> preload, but I think there is something beyond the timestamp that is
> incompatible.
If you tell me how to reproduce those other problems I can certainly
have a look.

Cheers,
Andrei