Re: [Libguestfs] [PATCH v4 0/3] v2v: Add -o rhv-upload output mode.
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