bwlp/qemu.git/docs/tools, branch master

Fix some typos in documentation and comments

2022-11-05T19:35:45+00:00

Most of them were found and fixed using codespell. Signed-off-by: Stefan Weil Reviewed-by: Peter Maydell Reviewed-by: Thomas Huth Reviewed-by: Stefan Hajnoczi Message-Id: <20221030105944.311940-1-sw@weilnetz.de> Signed-off-by: Laurent Vivier

qemu-img: Wean documentation and help output off '?' for help

2022-09-30T16:02:30+00:00

'?' for help is deprecated since commit c8057f951d "Support 'help' as a synonym for '?' in command line options", v1.2.0. We neglected to update output of qemu-img --help and the manual. Do that now. Signed-off-by: Markus Armbruster Message-Id: <20220908130842.641410-1-armbru@redhat.com> Reviewed-by: Kevin Wolf Signed-off-by: Kevin Wolf

misc: fix commonly doubled up words

2022-08-01T09:58:02+00:00

Signed-off-by: Daniel P. Berrangé Message-Id: <20220707163720.1421716-5-berrange@redhat.com> Reviewed-by: Peter Maydell Signed-off-by: Thomas Huth

Replace 'whitelist' with 'allow'

2022-07-18T18:24:36+00:00

Let's use more inclusive language here and avoid terms that are frowned upon nowadays. Message-Id: <20220711095300.60462-1-thuth@redhat.com> Reviewed-by: John Snow Reviewed-by: Alex Bennée Signed-off-by: Thomas Huth

vduse-blk: Add name option

2022-06-24T15:07:06+00:00

Currently we use 'id' option as the name of VDUSE device. It's a bit confusing since we use one value for two different purposes: the ID to identfy the export within QEMU (must be distinct from any other exports in the same QEMU process, but can overlap with names used by other processes), and the VDUSE name to uniquely identify it on the host (must be distinct from other VDUSE devices on the same host, but can overlap with other export types like NBD in the same process). To make it clear, this patch adds a separate 'name' option to specify the VDUSE name for the vduse-blk export instead. Signed-off-by: Xie Yongji Message-Id: <20220614051532.92-7-xieyongji@bytedance.com> Signed-off-by: Kevin Wolf

vduse-blk: Add serial option

2022-06-24T15:07:06+00:00

Add a 'serial' option to allow user to specify this value explicitly. And the default value is changed to an empty string as what we did in "hw/block/virtio-blk.c". Signed-off-by: Xie Yongji Message-Id: <20220614051532.92-6-xieyongji@bytedance.com> Signed-off-by: Kevin Wolf

qsd: document vduse-blk exports

2022-06-24T15:07:06+00:00

Document vduse-blk exports in qemu-storage-daemon --help and the qemu-storage-daemon(1) man page. Based-on: <20220523084611.91-1-xieyongji@bytedance.com> Cc: Xie Yongji Signed-off-by: Stefan Hajnoczi Message-Id: <20220525121947.859820-1-stefanha@redhat.com> Signed-off-by: Kevin Wolf

docs: Correct the default thread-pool-size

2022-05-25T10:01:38+00:00

Refer to 26ec190964 virtiofsd: Do not use a thread pool by default Signed-off-by: Liu Yiding Acked-by: Vivek Goyal Message-id: 20220413042054.1484640-1-liuyd.fnst@fujitsu.com Signed-off-by: Stefan Hajnoczi

nbd/server: Allow MULTI_CONN for shared writable exports

2022-05-12T11:10:52+00:00

According to the NBD spec, a server that advertises NBD_FLAG_CAN_MULTI_CONN promises that multiple client connections will not see any cache inconsistencies: when properly separated by a single flush, actions performed by one client will be visible to another client, regardless of which client did the flush. We always satisfy these conditions in qemu - even when we support multiple clients, ALL clients go through a single point of reference into the block layer, with no local caching. The effect of one client is instantly visible to the next client. Even if our backend were a network device, we argue that any multi-path caching effects that would cause inconsistencies in back-to-back actions not seeing the effect of previous actions would be a bug in that backend, and not the fault of caching in qemu. As such, it is safe to unconditionally advertise CAN_MULTI_CONN for any qemu NBD server situation that supports parallel clients. Note, however, that we don't want to advertise CAN_MULTI_CONN when we know that a second client cannot connect (for historical reasons, qemu-nbd defaults to a single connection while nbd-server-add and QMP commands default to unlimited connections; but we already have existing means to let either style of NBD server creation alter those defaults). This is visible by no longer advertising MULTI_CONN for 'qemu-nbd -r' without -e, as in the iotest nbd-qemu-allocation. The harder part of this patch is setting up an iotest to demonstrate behavior of multiple NBD clients to a single server. It might be possible with parallel qemu-io processes, but I found it easier to do in python with the help of libnbd, and help from Nir and Vladimir in writing the test. Signed-off-by: Eric Blake Suggested-by: Nir Soffer Suggested-by: Vladimir Sementsov-Ogievskiy Message-Id: <20220512004924.417153-3-eblake@redhat.com> Signed-off-by: Kevin Wolf

qemu-img: properly list formats which have consistency check implemented

2022-05-04T13:55:23+00:00

Simple grep for the .bdrv_co_check callback presence gives the following list of block drivers * QED * VDI * VHDX * VMDK * Parallels which have this callback. The presense of the callback means that consistency check is supported. The patch updates documentation accordingly. Signed-off-by: Denis V. Lunev CC: Kevin Wolf CC: Hanna Reitz Message-Id: <20220407083932.531965-1-den@openvz.org> Reviewed-by: Eric Blake Signed-off-by: Kevin Wolf