<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 21, 2018 at 10:33 PM Eric Blake <<a href="mailto:eblake@redhat.com">eblake@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/21/18 4:39 AM, Richard W.M. Jones wrote:<br>
> On Wed, Nov 21, 2018 at 09:25:05AM +0000, Richard W.M. Jones wrote:<br>
>> nbdkit: file.2: error: invalid request: offset and count are out of range: offset=196608 count=512<br>
> <br>
> Actually what happens even more precisely is that the underlying file<br>
> is not a multiple of 512 bytes (196624 ≡ 16 mod 512).<br>
> <br>
> qemu-img (the client) issues a request for the final "sector" of the<br>
> file which goes beyond the end of the file.<br>
<br>
I'm still hoping to fix that bug in qemu before the 3.1 release, but <br>
that date is getting close :)<br>
<br>
> <br>
> You can "fix" this by using the truncate filter<br>
> (<a href="https://github.com/libguestfs/nbdkit/blob/master/filters/truncate/nbdkit-truncate-filter.pod" rel="noreferrer" target="_blank">https://github.com/libguestfs/nbdkit/blob/master/filters/truncate/nbdkit-truncate-filter.pod</a>)<br>
> telling it to round up the size to the next multiple of 512 bytes:<br>
> <br>
> $ nbdkit --filter=truncate file file=disk -f -v round-up=512<br>
> <br>
> and this allows qemu-img to work:<br>
<br>
Yes, this is the right workaround for now.<br>
<br>
> <br>
> $ qemu-img info nbd://localhost<br>
> image: nbd://localhost:10809<br>
> file format: qcow2<br>
<br>
Invoking qemu-img without '-f $format' means that qemu-img has to probe <br>
the image to guess its format. Here, the probe succeeded, but in general <br>
this is insecure (if the file was 'raw', but the probe returned anything <br>
else, then a malicious guest could have tried to write metadata into the <br>
initial sector of their disk to try and get qemu to perform something on <br>
the guest's behalf due to the incorrect probe).  A more robust solution <br>
pairs either:<br>
<br>
qemu-nbd -f raw file.qcow2   <=>   qemu-img info -f qcow2 nbd://localhost<br>
nbdkit file file.qcow2   <=>   qemu-img info -f qcow2 nbd://localhost<br>
<br>
where NBD is exposing the qcow2 metadata over the network (whether via <br>
qemu-nbd or nbdkit), and the client HAS to be aware of qcow2, or:<br>
<br>
qemu-nbd -f qcow2 file.qcow2   <=>   qemu-img info -f raw nbd://localhost<br>
qemu-nbd -f qcow2 file.qcow2   <=>   any other nbd client<br>
<br>
where qemu-nbd is interpreting the qcow2 file, and only exposing the <br>
guest-visible data over the network.<br>
<br>
Or, repeating the above in a different formulation - when you are <br>
interested in serving qcow2 data over the network, you HAVE to have <br>
exactly one of your two endpoints be aware that the qcow2 format is <br>
involved - either the server is agnostic and the client interprets qcow2 <br>
(the former setup), or the server interprets qcow2 and the client is <br>
agnostic (the latter setup).<br>
<br>
Then, as Rich pointed out, when you expose qcow2 over NBD (the former <br>
setup), the current NBD protocol does NOT allow resizes - so while <br>
reading the image works okay, writing to the image is likely to hit <br>
ENOSPC unless you pre-allocated the .qcow2 file being served.  That is <br>
likely to change upstream in the next six months (it's on my todo list <br>
to get NBD resize implemented), but there's still a percolation delay <br>
from upstream to using it in default OS installs.  On the other hand, <br>
when you expose raw over NBD by using qemu-nbd to convert qcow2 to raw <br>
on the server end, then the server can resize things as needed and the <br>
client need not be aware that qcow2 is even involved.<br>
<br></blockquote><div>After nbd resize implemented, we can get actual disk size instread of 'unavailable', right?</div><div>Will it support disk extend, or just support disk shrinking? <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As for why nbdkit doesn't have a plugin for exposing a local qcow2 file <br>
as raw - we don't see the point in duplicating what qemu-nbd can already <br>
do. Yes, someone could write such a plugin, but it will probably have <br>
worse performance than what you can already get out of using qemu-nbd as <br>
the server.<br>
<br>
> However the fundamental problem remains that you're exporting qcow2<br>
> bytes over the NBD connection which is not really what you wanted to<br>
> do.<br>
<br>
Maybe it is, if the qcow2 file is fully preallocated, but yeah, until <br>
NBD resize exists, most people don't want that combination.<br>
<br>
> <br>
> You should use qemu-nbd instead since it understands qcow2 natively,<br>
> or use raw format disks if you want to use nbdkit for its other<br>
> features.<br>
> <br>
> Rich.<br>
> <br>
<br>
-- <br>
Eric Blake, Principal Software Engineer<br>
Red Hat, Inc.           +1-919-301-3266<br>
Virtualization:  <a href="http://qemu.org" rel="noreferrer" target="_blank">qemu.org</a> | <a href="http://libvirt.org" rel="noreferrer" target="_blank">libvirt.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Best regards,</div><div dir="ltr">-----------------------------------<br></div><div dir="ltr">Han Han<br>Quality Engineer<br>Redhat.<br><br>Email: <a href="mailto:hhan@redhat.com" target="_blank">hhan@redhat.com</a><br>Phone: +861065339333<br></div></div></div></div></div></div></div></div>