[PATCH] qemu: Add vhost-user-blk unix socket to support server mode

Peter Krempa pkrempa at redhat.com
Tue Mar 28 14:30:14 UTC 2023


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


More information about the libvir-list mailing list