On Sat, Mar 23, 2019 at 12:21:11PM +0000, Richard W.M. Jones wrote:
On Sat, Mar 23, 2019 at 06:57:14AM -0500, Eric Blake wrote:
> And what workaround would that be? Looking at the qemu patch, the
> problem is that qemu asked for "base:allocation" and nbdkit replied with
> 0 contexts. The workaround would either be to reply with
> NBD_REP_ERR_UNSUP (the behavior before NBD_OPT_SET_META_CONTEXT was
> added), or to implement "base:allocation" (even if we implement the
> poor-man's version that always reports that the entire image is data,
> for all requests, without any feedback from the plugins). The former
> feels odd, but the latter seems oddly appealing as progress towards our
> end goal (kind of how our initial implementation of NBD_CMD_WRITE_ZEROES
> was always advertised even before we finished wiring up plug support).
A good point here is what happens with the block-status branch[1].
Let's see:
$ ./nbdkit memory size=64M --run '/home/rjones/d/qemu/qemu-img convert $nbd
/var/tmp/out'
qemu-img: Payload too large
nbdkit: memory.1: error: write reply: NBD_CMD_BLOCK_STATUS: Broken pipe
Oh dear. I believe this is actually a bug in the block status code so
let's see if I can narrow this down first ...
OK I fixed this bug (in nbdkit).
The block-status branch *works* with qemu 2.12.0, so another option
here is to do nothing and wait until that work is finished and merged.
NB During this I discovered another (but minor) bug in qemu. If you
feed qemu a long series of block status replies then it eventually
closes the connection. However it does not print an error message.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/