<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Apr 12, 2018 at 5:42 PM Eric Blake <<a href="mailto:eblake@redhat.com">eblake@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/12/2018 05:24 AM, Richard W.M. Jones wrote:<br>
<br>
> I don't think we have nbd-server in RHEL, and in any case wouldn't it<br>
> be better to use qemu-nbd?<br>
> <br>
> You just start a new qemu-nbd process instead of faffing around with<br>
> configuration files, kill the qemu-nbd process when you're done, and</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> qemu-nbd supports qcow2 already.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That, and qemu-nbd supports extensions such as NBD_CMD_BLOCK_STATUS and<br>
NBD_OPT_STRUCTURED_REPLY that nbd-server has not implemented yet; a qemu<br>
NBD client talking to a qemu-nbd server is thus going to be able to take<br>
advantage of those extensions for better performance that would not be<br>
possible with a qemu NBD client talking to an nbd-server instance (at<br>
least, not without someone implementing the new features there).  And<br>
this is no different from the situation where nbdkit as the server lacks<br>
several features; the current rhv-upload patches use a python plugin to<br>
nbdkit, which is implemented as serializing all requests; while using<br>
qemu-nbd as the server would allow parallel requests to be in flight<br>
simultaneously.<br></blockquote><div><br></div><div>Right, qemu-nbd will be better. </div><div><br></div><div>The manual is not very useful - do we have examples somewhere?</div><div><br></div><div>We will consider this for 4.3.</div><div><br></div><div>Nir</div><div><br></div></div></div>