18.01.2019 11:15, Vladimir Sementsov-Ogievskiy wrote:
> 17.01.2019 22:36, Eric Blake wrote:
>> I got tired of debugging whether a server was advertising the
>> correct things during negotiation by inspecting the trace
>> logs of qemu-io as client - not to mention that without SOME
>> sort of client tracing particular commands, we can't easily
>> regression test the server for correct behavior. The final
>> straw was at KVM Forum, when Nir asked me to make sure there
>> was a way to easily determine if an NBD server is exposing what
>> we really want (and fixing x-dirty-bitmap to behave saner fell
>> out as a result of answering that question).
>>
>> I note that upstream NBD has 'nbd-client -l $host' for querying
>> just export names (with no quoting, so you have to know that
>> a blank line means the default export), but it wasn't powerful
>> enough, so I implemented 'qemu-nbd -L' to document everything.
>> Upstream NBD has separate 'nbd-client' and 'nbd-server' binaries,
>> while we only have 'qemu-nbd' (which is normally just a server,
>> but 'qemu-nbd -c' also operates a second thread as a client).
>> Our other uses of qemu as NBD client are for consuming a block
>> device (as in qemu-io, qemu-img, or a drive to qemu) - but those
>> binaries are less suited to something so specific to the NBD
>> protocol.
>>
>> Bonus: As a result of my work on this series, nbdkit now supports
>> NBD_OPT_INFO (my interoperability testing between server
>> implementations has been paying off, both at fixing server bugs,
>> and at making this code more reliable across difference in valid
>> servers).
>>
>> Also available at:
>> https://repo.or.cz/qemu/ericb.git qemu-nbd-list-v4
>>
>> Currently based on master.
>>
>> Since v3:
>> - 1 new patch (1/21)
>> - split old patch 15/19 into two (16,17/21)
>> - retitle two patches (git backport-diff doesn't do too well at showing
>> the diff on a retitled patch; 5,11/21)
>> - fix review comments from Rich, Vladimir
>>
>> 001/21:[down] 'iotests: Make 233 output more reliable'
>> 002/21:[----] [--] 'maint: Allow for EXAMPLES in texi2pod'
>> 003/21:[----] [--] 'qemu-nbd: Enhance man page'
>
> Interesting, I don't get it again. Searched in outlook online, I found only
> v2 of it,
> checked spam folder and filters. Magic.
>
> anyway, I can look at
> https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg04328.html
>
>
just look at it in your qemu-nbd-list-v4 tag:
> Only expose MBR partition @var{num}. Understands physical partitions
> 1-4 and logical partitions 5-8.
I'm afraid, I'm too lazy to sort out these things I don't know, so just
believe. It at least
corresponds to limits in code that it should be 1 <= partition <= 8 ;)
> @item -c, --connect=@var{dev}
> Connect @var{filename} to NBD device @var{dev} (Linux only).
> @item -d, --disconnect
> Disconnect the device @var{dev} (Linux only).
Yes, and we now have clean code which establish this limitation
> @item -e, --shared=@var{num}
> Allow up to @var{num} clients to share the device (default
> @samp{1}). Safe for readers, but for now, consistency is not
> guaranteed between multiple writers.
Hmm, don't understand, why you decided to move @samp{1}). on the following
line, it looks
better as it was. And with a period it's only 69 symbols, the file have a lot
longer lines.
> Start a server listening on port 10809 that exposes only the
> guest-visible contents of a qcow2 file, with no TLS encryption, and
> with the default export name (an empty string). The command is
> one-shot, and will block until the first successful client
> disconnects:
>
> @example
> qemu-nbd -f qcow2 file.qcow2
> @end example
>
> Start a long-running server listening with encryption on port 10810,
> and require clients to have a correct X.509 certificate to connect to
> a 1 megabyte subset of a raw file, using the export name 'subset':
>
> @example
> qemu-nbd \
> --object tls-creds-x509,id=tls0,endpoint=server,dir=/path/to/qemutls \
> --tls-creds tls0 -t -x subset -p 10810 \
> --image-opts
> driver=raw,offset=1M,length=1M,file.driver=file,file.filename=file.raw
> @end example
I don't know tls-related, the other options looks fine.
upd (decided to run the command, with dropped tls):
looks fine but not work, as s/length/size.
>
> Serve a read-only copy of just the first MBR partition of a guest
> image over a Unix socket with as many as 5 simultaneous readers, with
> a persistent process forked as a daemon:
>
> @example
> qemu-nbd --fork -t -e 5 -s /path/to/sock -p 1 -r -f qcow2 file.qcow2
> @end example
Oops. s/-s/-k/, s/-p/-P/, and idea: may be, use self-descriptive long option
names in
examples?
>
> Expose the guest-visible contents of a qcow2 file via a block device
> /dev/nbd0 (and possibly creating /dev/nbd0p1 and friends for
> partitions found within), then disconnect the device when done.
> @emph{CAUTION}: Do not use this method to mount filesystems from an
> untrusted guest image - a malicious guest may have prepared the image
> to attempt to trigger kernel bugs in partition probing or file system
> mounting.
>
> @example
should we note, that nbd kernel-module should be loaded for this to work?
> qemu-nbd -c /dev/nbd0 -f qcow2 file.qcow2
> qemu-nbd -d /dev/nbd0
> @end example
With fixed wrong option names and s/length/size:
for 03/21:
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
--
Best regards,
Vladimir
