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

[Richard W.M. Jones]

On Thu, Mar 08, 2018 at 09:41:38AM -0600, Eric Blake wrote:
> On 03/08/2018 06:29 AM, Richard W.M. Jones wrote:
> 
> >NBD (the protocol) doesn't "know" about qcow2 files.  You can serve
> >any file you want as a range of bytes, including qcow2, but that
> >requires whatever is consuming those bytes to then do the qcow2
> >en-/decoding.  (Which means effectively the client has to be qemu
> >because nothing else can parse qcow2 reliably).  In the qemu-img
> >convert case above this all works because qemu-img (ie. qemu) is the
> >client, and it does the encoding of qcow2, and we're just shuffling a
> >byte stream to oVirt imageio.
> 
> One caveat: NBD cannot (yet) resize disks (there is a proposal to
> implement a new command that would optionally allow an NBD client to
> request a resize, and/or a server to advertise an updated size back
> to the client beyond the initial size learned at connect, but that
> proposal still needs ironing out and an initial implementation).  As
> such, if you are serving a qcow2 file as raw bytes over NBD, you
> MUST be sure that the NBD server already has a sufficient size for
> the file it is serving, because the client interpreting qcow2 will
> not be able to do anything if its qcow2 usage patterns require more
> space than the NBD server already advertised.

That's a good point actually.  The current patch set assumes
size == virtual size, which is OK for raw, but could be insufficient
(in extremis) for qcow2.  Added to the to-do list.

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