[Libguestfs] [PATCH v4 0/3] v2v: Add -o rhv-upload output mode.

[Nir Soffer]

On Wed, Mar 7, 2018 at 12:18 AM Richard W.M. Jones <rjones at redhat.com>
wrote:

> Previous versions:
>   v3: https://www.redhat.com/archives/libguestfs/2018-March/msg00000.html
>   v2:
> https://www.redhat.com/archives/libguestfs/2018-February/msg00177.html
>   v1:
> https://www.redhat.com/archives/libguestfs/2018-February/msg00139.html
>
> This completely rethinks the approach taken by the previous patches.
>
> Instead of trying to involve qemu's curl driver, this uses a small
> Python 3 nbdkit plugin to interface between qemu and the oVirt server.
>
> The data path is:
>
>   qemu-img convert  ------->   nbdkit   ------->   oVirt imageio
>                       nbd                 https
>

What is the advantage of this for raw files? Why not:

    v2v -> ovirt imageio?

And how qcow2 files will be handled? when I tried nbdkit few month ago
I could not make it handle qcow2 files. Maybe I had to write a plugin?

We considered using this flow when we download/upload images,
to support on-the-fly image conversion:

    raw file -> qemu-img convert -> nbdkit -> qcow2 stream -> imageio ->
http client

And same for uploading, e.g. uploading qcow2 and writing raw image.

If this is possible using nbdkit plugin, can we ruse the same plugin in
different applications, or we must implement the plugin in each application?


> There are two Python scripts included.  One is the nbdkit plugin.  The
> other creates the VM.  As with the previous patches, these scripts get
> embeded in virt-v2v at compile time, so effectively there is no API
> contract between virt-v2v & the Python code.
>
> With this patch series I am able to (mostly) successfully convert VMs
> from local disk to oVirt 4.2, with full end-to-end streaming.  There
> is some room for optimization -- in particular uploads are currently
> rather slow because we rely on qemu-img batching small requests into
> large ones which it doesn't do well, and instead the nbdkit plugin
> could batch small writes into larger ones.  Also I noticed (but only
> one time) that very long transfers would cause the oVirt ticket to
> expire, even though we were writing the whole time.
>

On the host, the ticket is extended regularly, based on the activity.

On the proxy we currently have 3600 seconds timeout, and the ticket
is never extended. I think we should have the same mechanism as
we do on the host.

Nir

There are still a few unresolved issues (see patch 3/3) so this is not
> quite ready to go upstream yet, but can still be reviewed.  Patches 1
> & 2 are the same as posted before.
>
> I did not yet test qcow2 uploads.  Those are "interestingly" different
> because qcow2 will require us to read from the remote oVirt server as
> well as just stream/write to it.  The pread method for that is written
> but has not been tested.
>
> Rich.
>
> _______________________________________________
> Libguestfs mailing list
> Libguestfs at redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180308/066c848a/attachment.htm>