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

[Eric Blake]

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.

When pairing qemu-nbd as server with qemu or qemu-io as client, your 
options are:
1. 'qemu-nbd -f qcow2' + 'qemu-io -f raw': the client sees only what the 
guest would see, and no qcow2 metadata. The server may resize the host's 
qcow2 image as needed to continue to provide the same size guest image 
to the client, but the client can't take direct advantage of any qcow2 
features.  This is easiest.
2. 'qemu-nbd -f raw' + 'qemu-io -f qcow2': the client sees the qcow2 
metadata directly, and must interpret from that what the guest would 
see. The server never resizes the image, so hopefully you preallocated 
it to be large enough for anything the guest wants to do with qcow2. 
The client can use whatever qcow2 features it wants.  This is where I've 
seen people fail to preallocate, and then wonder why the client fails.

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