On Tue, Mar 21, 2023 at 09:46:44 +0800, Zhenguo Yao wrote:
Peter Krempa <pkrempa(a)redhat.com> 于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.
I don't really find this argument as compelling. If the server doesn't
want to accept the connection it can refuse it.
So, we set QEMU to server mode in
vhost-user network. And, we
follow this in vhost-user blk.
I really don't want us to add another instance of this. I think that the
server mode for vhost-user network was a mistake. It's really poorly
documented and the semantics are very non-obvius.
Specifically qemu being stuck until the "clients" connect to it is a
very broken semantic and users don't expect it.
Additionally you have the issue of distinct behaviour with hotplug where
the VM is not stopped.
Could you please show me which race conditions will come with when
using server mode in vhost-user blk?
The race condition is when you don't use 'wait=on'. The race is between
qemu starting up and wanting to use the disk and your "client"
connecting to it.
'wait=off' doesn't have that but has awful semantics which I really
don't want to add more of to libvirt.
Your use case seems more of a workaround than a real need for this
feature.