[Libguestfs] v2v: -o rhv-upload - oVirt imageio random I/O APIs

[Nir Soffer]

On Wed, Mar 21, 2018 at 2:47 PM Richard W.M. Jones <rjones at redhat.com>
wrote:

> On Wed, Mar 21, 2018 at 11:20:13AM +0000, Nir Soffer wrote:
> > Hi,
> >
> > I updated the random I/O documentation patch:
> > https://gerrit.ovirt.org/#/c/89022/
> >
> > I would to get your comments on this before we complete the
> implementation.
>
> I want to check a couple of things:
>
> (1) The OPTIONS request uses path ‘/images/%2A’ (ascii encoding of
> ‘*’).  That is literally what is sent over the wire?
>

Yes, you can send the upload path /images/ticket-uuid or the special
/images/*

Both should behave in the same way.

(2) We can make the OPTIONS request without needing to send an
> Authorization header


Authorization is always ignored, there is no need to send it to a server
supporting
options.


> or having any ticket or disk in mind?  This is
> necessary because the NBD protocol requires us to send back the
> 'can-trim' (etc) flags very early on, long before we have created a disk.
>

Then you should use the special /images/* that does not require a ticket or
an image.

But not that trim will do nothing in the first version, and later it will
be useful
only for images on file storage, and some images on block storage (depending
if the user selected wipe-after-delete). This is explain in the section
about
trim.

Even when trim will be implemented for some image, it may not zero data.

I hope that the semantics match what qemu-img/nbdkit expects?

If we cannot implement a useful trim now, maybe we should not implement
it at all, so virt-v2v cat tell that trim is not supported using OPTIONS?

Nir


>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180321/a7e1aba2/attachment.htm>