Peter Krempa <pkrempa@xxxxxxxxxx> 于2023年3月16日周四 21:51写道：
>
> On Thu, Mar 09, 2023 at 16:58:07 +0800, Zhenguo Yao wrote:
> > qemu support server mode when using vhost-user-blk disk.
> > Let libvirt to support this.
>
> Could you please elaborate how you expect to use this?
>
> I'm asking because server mode comes with a integrated set of race
> conditions:
>
We want QEMU to server mode because when other side(for example SPDK
or DPDK) acted as server,
it restarts because of some reasons. Plants of clients will try to
reconnect to the server together. This
will take pressure on the server. So, we set QEMU to server mode in
vhost-user network. And, we
follow this in vhost-user blk.
Could you please show me which race conditions will come with when
using server mode in vhost-user blk?
> > diff --git a/tests/qemuxml2argvdata/disk-vhostuser-numa.x86_64-latest.args b/tests/qemuxml2argvdata/disk-vhostuser-numa.x86_64-latest.args
> > index 75b3232dad..ea4b227328 100644
> > --- a/tests/qemuxml2argvdata/disk-vhostuser-numa.x86_64-latest.args
> > +++ b/tests/qemuxml2argvdata/disk-vhostuser-numa.x86_64-latest.args
> > @@ -31,9 +31,11 @@ XDG_CONFIG_HOME=/tmp/lib/domain--1-QEMUGuest1/.config \
> > -device '{"driver":"piix3-usb-uhci","id":"usb","bus":"pci.0","addr":"0x1.0x2"}' \
> > -chardev socket,id=chr-vu-virtio-disk0,path=/tmp/vhost1.sock \
> > -device '{"driver":"vhost-user-blk-pci","bus":"pci.0","addr":"0x2","chardev":"chr-vu-virtio-disk0","id":"virtio-disk0","bootindex":1}' \
> > --chardev socket,id=chr-vu-virtio-disk1,path=/tmp/vhost1.sock,reconnect=10 \
> > +-chardev socket,id=chr-vu-virtio-disk1,path=/tmp/vhost1.sock,server=on,wait=off \
>
> Emphasizing that 'wait=off' is used for the chardev backend.
>
> When starting such a VM assuming only 1 storage device is being started
> you have a very short window where the client must connect to it and
> start the vhost session. Otherwise the disk will not be visible by the
> VM and it will not boot.
>
> This is a bit different than vhost-user network as it's required right
> at the start.
>
> Even then vhost-user networking which supports server mode sets
> 'wait=on'. But this is problematic on a different level. The VM is stuck
> until the vhost connection is established
>
> Similarly it also creates a problem when hotpluggingg as there 'wait=on'
> doesn't really exist, thus it behaves differently.
>
Yes，you are right. wait=on is needed in this situation.
> Thus unless there is a good reason to do so I find that the 'server'
> mode is not useful here.
>
