Libguestfs - Oct 2016 - Re: Extracting files from OVA is bad

Hi,

just to keep this thread alive, here are few comments on the progress.
(Mostly for those not following QEMU mailing lists.)


On Fri, 9 Sep 2016 15:18:02 +0300
Roman Kagan <rkagan@virtuozzo.com> wrote:
> On Fri, Sep 09, 2016 at 03:08:31PM +0300, Roman Kagan wrote:
> > On Fri, Sep 09, 2016 at 01:03:49PM +0200, Tomáš Golembiovský wrote:
> > I think something like this can be done for your usecase, e.g. you can
> > create qcow2 images with images from the archive as backing files. 
One
> > possibility to do so is to have a loopback block device on top of the
> > archive with appropriate offset and length
Using the loopback device would be the easiest solution in the sense
that it wouldn't require code changes outside virt-v2v. But, there's a
big issue: it requires root privileges. That's why I cast this idea away
from the beginning and decided to use that only as the last resort.


Other suggestion was to use qemu-nbd because it already has --offset
argument to set where the disk starts. It turned out that:

a)  The code for --offset is buggy and clients may attempt to read data
    outside the backing file, because qemu-nbd reports wrong size of the
    disk. Such request will inevitably fail.

b)  We also need to be able to specify the size of the disk. It cannot
    be left undefined and limited only by the length of underlying file.
    Security reasons aside, there are also some practical reasons. E.g.
    it turned out that VMDK format stores some footer at the end of the
    disk. If the size of the disk is not set properly the VMDK driver
    fails to find the footer and regards the disk as invalid.


I fixed the issues and sent patches to QEMU [1][2].

Quickly somebody commented [3] that doing this in qemu-nbd is not the
right idea and it should be done in the raw driver...
> Alternatively, you can make one layer less if you teach QEMU raw block
> driver to recongnize offset and length options.
> 
> Roman.
... that is something what Roman suggested from the start.

It'll be more complicated than fixing qemu-nbd, but I gave it a shot. I
have sent the first version [4] of that to QEMU. I would expect it going
in right away, there's still some work to be done.

That being said, I also have POC ready (attached) for virt-v2v. It's
rather dirty as it contains some 'tar' invocations to get the necessary
information from the archive. There are some OCAML modules for working
with tar archives, but I didn't try any yet.

Good thing is that QEMU people are not against putting the size & offset
parameters into raw driver. Still it may turn out to be a task too hard.
In that case, as a fallback, we can still use the NBD approach. We don't
have to use qemu-nbd. We could also try to submit code for size & offset
into the nbd-server in NBD tools (the defacto reference implementation).
But that's something I didn't pursue yet.


    Tomas

[1] https://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg04554.html
[2] https://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg04556.html
[3] https://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg04578.html
[4] https://lists.nongnu.org/archive/html/qemu-block/2016-10/msg00008.html

-- 
Tomáš Golembiovský <tgolembi@redhat.com>

On Mon, 3 Oct 2016 14:49:38 +0200
Tomáš Golembiovský <tgolembi@redhat.com> wrote:
> [...] I would expect it going
> in right away, there's still some work to be done.
Erm, nasty typo. "I wouldn't" is what I meant.


    Tomas

-- 
Tomáš Golembiovský <tgolembi@redhat.com>