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

Libguestfs mailing list

Reply via email to