Libguestfs - Mar 2018 - v2v: -o rhv-upload - oVirt imageio random I/O APIs

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.

Thanks,
Nir

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.
Looks great to me, we can work with this.

There's no mention of alignment, so can I assume that we can make
arbitrarily aligned requests?  (although it's not likely we will)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

On Wed, Mar 21, 2018 at 1:25 PM Richard W.M. Jones <rjones@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.
>
> Looks great to me, we can work with this.
>
> There's no mention of alignment, so can I assume that we can make
> arbitrarily aligned requests?  (although it's not likely we will)
>
I hoped that I can get away with requiring aligned zeros, but it seems that
we should implement it once instead of in all clients.

Nir

>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
>

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?

(2) We can make the OPTIONS request without needing to send an
Authorization header 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.

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

On Wed, Mar 21, 2018 at 12:47:18PM +0000, Richard W.M. Jones
wrote:
> 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.
Actually this sentence isn't true, but I'm still interested in
the answer to these questions.

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

On Wed, Mar 21, 2018 at 2:47 PM Richard W.M. Jones <rjones@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
>