[Libguestfs] [Qemu-devel] [qemu-img] support for XVA

Gandalf Corvotempesta gandalf.corvotempesta at gmail.com
Wed Nov 15 21:50:08 UTC 2017


https://stacklet.com/downloads/XenServer-XVA-Template-Debian-7.8-Lightweight-x86

Some XVAs

Il 15 nov 2017 10:42 PM, "Gandalf Corvotempesta" <
gandalf.corvotempesta at gmail.com> ha scritto:

> I'm thinking on how to prove you a sample XVA
> I have to create (and populate) a VM because an empty image will result in
> an empty XVA
> And a VM is 300-400Mb as minimum
>
> Il 15 nov 2017 10:30 PM, "Max Reitz" <mreitz at redhat.com> ha scritto:
>
>> On 2017-11-15 21:41, Gandalf Corvotempesta wrote:
>> > 2017-11-15 21:29 GMT+01:00 Richard W.M. Jones <rjones at redhat.com>:
>> >> Gandalf, is there an XVA file publically available (pref. not
>> >> too big) that we can look at?
>> >
>> > I can try to provide one, but it's simple:
>> >
>> > # tar tvf 20160630_124823_aa72_.xva.gz | head -n 50
>> > ---------- 0/0           42353 1970-01-01 01:00 ova.xml
>> > ---------- 0/0         1048576 1970-01-01 01:00 Ref:175/00000000
>> > ---------- 0/0              40 1970-01-01 01:00
>> Ref:175/00000000.checksum
>> > ---------- 0/0         1048576 1970-01-01 01:00 Ref:175/00000001
>> > ---------- 0/0              40 1970-01-01 01:00
>> Ref:175/00000001.checksum
>> > ---------- 0/0         1048576 1970-01-01 01:00 Ref:175/00000003
>> > ---------- 0/0              40 1970-01-01 01:00
>> Ref:175/00000003.checksum
>> > ---------- 0/0         1048576 1970-01-01 01:00 Ref:175/00000004
>> > ---------- 0/0              40 1970-01-01 01:00
>> Ref:175/00000004.checksum
>> > ---------- 0/0         1048576 1970-01-01 01:00 Ref:175/00000005
>> > ---------- 0/0              40 1970-01-01 01:00
>> Ref:175/00000005.checksum
>> > ---------- 0/0         1048576 1970-01-01 01:00 Ref:175/00000006
>> > ---------- 0/0              40 1970-01-01 01:00
>> Ref:175/00000006.checksum
>> > ---------- 0/0         1048576 1970-01-01 01:00 Ref:175/00000007
>> > ---------- 0/0              40 1970-01-01 01:00
>> Ref:175/00000007.checksum
>> > ---------- 0/0         1048576 1970-01-01 01:00 Ref:175/00000009
>> > ---------- 0/0              40 1970-01-01 01:00
>> Ref:175/00000009.checksum
>> > ---------- 0/0         1048576 1970-01-01 01:00 Ref:175/00000010
>> > ---------- 0/0              40 1970-01-01 01:00
>> Ref:175/00000010.checksum
>> >
>> >
>> > You can ignore the ova.xml and just use the "Ref:175" directory.
>> > Inside the XVA you'll fine one "Ref" directory for each virtual disk
>> > (ref number is different for each disk)
>> > Inside each Ref directory, you'll get tons of 1MB file, corrisponding
>> > to the RAW image.
>> > You have to merge these files in a single raw file with just an
>> > exception: numbers are not sequential.
>> > as you can see above, we have: 00000000, 00000001, 00000003
>> >
>> > The 00000002 is missing, because it's totally blank. XenServer doesn't
>> > export any empty block, thus it will skip the corrisponding 1MB file.
>> > When building the raw image, you have to replace empty blocks with 1MB
>> > full of zeros.
>> >
>> > This is (in addition to the tar extract) the most time-consuming part.
>> > Currently I'm rebuilding a 250GB image, with tons of files to be
>> > merge.
>> > If qemu-img can be patched to automatically convert this kind of
>> > format, I can save about 3 hours (30 minutes for extracting the
>> > tarball, and about 2 hours to merge 250-300GB image)
>>
>> Hmmm...  OK, so as Rich said, you can use the raw driver with an offset
>> and a size.  And you can use the null-co driver to emulate holes.  And
>> qemu-img convert supports concatenation.
>>
>> Taking all of that together, it should be possible to create an input
>> "file" per 1 MB block and concatenate all of those with qemu-img
>> convert.  The only issue is that it'll get you a *really* long command
>> line.
>>
>> (And you'll still have to gunzip the archive before, of course.)
>>
>> I'll try to write a script, but of course it's hart without an example...
>>
>> Max
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20171115/127d0e55/attachment.htm>


More information about the Libguestfs mailing list