On Fri, Apr 20, 2018 at 10:18:18 -0400, John Ferlan wrote:
On 04/18/2018 01:30 PM, Daniel P. Berrangé wrote:
> There is a race condition when spawning QEMU where libvirt has spawned
> QEMU but the monitor socket is not yet open. Libvirt has to repeatedly
> try to connect() to QEMU's monitor until eventually it succeeds, or
> times out. We use kill() to check if QEMU is still alive so we avoid
> waiting a long time if QEMU exited, but having a timeout at all is still
> unpleasant.
>
> With QEMU 2.12 we can pass in a pre-opened FD for UNIX domain or TCP
> sockets. If libvirt has called bind() and listen() on this FD, then we
> have a guarantee that libvirt can immediately call connect() and
> succeed without any race.
>
> Although we only really care about this for the monitor socket and agent
> socket, this patch does FD passing for all UNIX socket based character
> devices since there appears to be no downside to it.
>
> We don't do FD passing for TCP sockets, however, because it is only
> possible to pass a single FD, while some hostnames may require listening
> on multiple FDs to cover IPv4 and IPv6 concurrently.
>
> Reviewed-by: John Ferlan <jferlan(a)redhat.com>
> Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
> ---
> src/qemu/qemu_command.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 52 insertions(+), 2 deletions(-)
>
This one is now affected by Peter's recent xml2argv adjustment for:
tests/qemuxml2argvdata/disk-drive-write-cache.x86_64-latest.args
which now fails w/ :
253) QEMU XML-2-ARGV disk-drive-write-cache.x86_64-latest
... libvirt: QEMU Driver error : Unable to bind to UNIX socket path
'/tmp/lib/domain--1-QEMUGuest1/monitor.sock': No such file or directory
FAILED
I'm kind of glad I've added this test :)
because the qemuProcessCreatePretendCmd doesn't allow this code
to
distinguish that it shouldn't attempt a bind/listen <sigh>
I "think" this may require moving the socket setup code into
qemuProcessLaunch or somehow passing a flag into BuildCommandLine to
tell it not to do anything "real".
Yeah. The command line generator should be inert to the host, so this
needs to be moved to the preparation steps.