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