On Tue, Mar 21, 2023 at 09:46:44 +0800, Zhenguo Yao wrote: > 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. 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.
