Am 17.08.2020 um 19:19 hat Nir Soffer geschrieben:
> On Thu, Aug 13, 2020 at 7:36 PM Kevin Wolf <kwolf@redhat.com> wrote:
>
> > Instead of implementing qemu-nbd --offset in the NBD code, just put a
> > raw block node with the requested offset on top of the user image and
> > rely on that doing the job.
> >
> > This does not only simplify the nbd_export_new() interface and bring it
> > closer to the set of options that the nbd-server-add QMP command offers,
> > but in fact it also eliminates a potential source for bugs in the NBD
> > code which previously had to add the offset manually in all relevant
> > places.
> >
>
> Just to make sure I understand this correctly -
>
> qemu-nbd can work with:
>
> $ qemu-nbd 'json:{"driver": "file", "filename": "test.raw"}'
>
> And:
>
> $ qemu-nbd 'json:{"driver": "raw", "file": {"driver": "file",
> "filename": "test.raw"}}'
>
> I assumed that we always create the raw node?
No, the first form creates only the 'file' node without a 'raw' node on
top. For all practical matters, this should be the same in qemu-img or
qemu-nbd. For actually running VMs, omitting the 'raw' node where it's
not needed can improve performance a little.
We did not check if we have different performance with the extra raw node.
Since in our use case (copying images) small reads/writes are unlikely, I don't
think it will make a difference.
What is true is that if you use a filename without specifying the driver
(i.e. you rely on format probing), you'll get a 'raw' node on top of
the 'file' node.
> oVirt always uses the second form to make it easier to support offset,
> size, and backing.
> https://github.com/oVirt/ovirt-imageio/blob/2021164d064227d7c5e03c8da087adc66e3a577e/daemon/ovirt_imageio/_internal/qemu_nbd.py#L104
>
> This also seems to be the way libvirt builds the nodes using -blockdev.
libvirt actually has a BZ to avoid the 'raw' node for performance when
it's not needed.
> Do we have a way to visualize the internal node graph used by
> qemu-nbd/qemu-img?
No, but as long as you explicitly specify the driver, you get exactly
what you specified.
So this is not really needed then.
For exploring what happens, you can pass the same json: filename to QEMU
(maybe with -hda) and then use the monitor to inspect the state.
Kevin