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

On Wed, Mar 14, 2018 at 06:56:19PM +0000, Nir Soffer
wrote:
> I posted documentation for the new API optimized for random I/O:
> https://gerrit.ovirt.org/#/c/89022/
Wish I'd had this documentation when I started the patch :-)
Yes, it's much clearer.
> I changed POST to PATCH to match the existing /tickets API, and
> this also seems to be more standard way to do such operations.
Assuming Python httplib will allow us to put anything in the method
argument of http.putrequest then this doesn't appear to make any
significant difference so that's fine.  Also we can set the
"flush"
(ie. FUA) parameter to match the NBD request.
> Please check and comment if this makes sense and serves the v2v
> use case or other uses case we missed.
> 
> I think we can implement all of this for 4.2.4, but:
> 
> - using simple zero loop, as in https://gerrit.ovirt.org/#/c/88793/.
>   later we can make it more efficient.
> - trim is a noop, maybe we will be able to support it in 4.3
> - flush - may be noop now (all requests will implicitly flush).
I don't think we really need trim or flush.  They're only minor
optimizations.  Zero is the one which is required.

FWIW NBD allows you to flush ranges or flush the whole disk, in case
that matters (your proposal only allows you to flush the whole disk).
> I think we better have complete API with partial or simpler
> implementation now, to minimize the hacks needed in v2v and
> other clients.
Agreed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

On Wed, Mar 14, 2018 at 09:07:31PM +0000, Nir Soffer
wrote:
> On Wed, Mar 14, 2018 at 9:04 PM Richard W.M. Jones
<rjones@redhat.com>
> wrote:
> > FWIW NBD allows you to flush ranges or flush the whole disk, in case
> > that matters (your proposal only allows you to flush the whole disk).
> >
> 
> What is the use case for flushing ranges?
The use case is that (eg) your editor inside a VM calls fdatasync.

This could be implemented by the hypervisor either by flushing the
entire virtual disk, or by writing just the blocks associated with the
file being editing and setting the FUA flag on those writes.  The
first one flushes out far more data than is really necessary to
satisfy the request.

I don't think any of this applies to oVirt imageio, so we don't need
it to be implemented.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

On 03/14/2018 04:07 PM, Nir Soffer wrote:
> 
> What is the use case for flushing ranges? I guess we will have one
> or few flushes per images.
> 
> Looking at sync_file_range(2), it does not seem to be a safe way to
> flush:
Wow - I didn't know there was a syscall for flushing ranges.  Even if it 
is unusable for our purposes given the warnings in its documentation, 
and unneeded since neither qemu nor NBD flush by ranges.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org