[libvirt] [PATCH v3 2/4] qemu: support passing pre-opened UNIX socket listen FD

[John Ferlan]

On 05/17/2018 09:40 AM, 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.
> 
> Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> ---
>  src/qemu/qemu_command.c                       | 64 ++++++++++++++++++-
>  src/qemu/qemu_command.h                       |  4 ++
>  .../disk-drive-write-cache.x86_64-latest.args |  3 +-
>  ...irtio-scsi-reservations.x86_64-latest.args |  3 +-
>  tests/qemuxml2argvmock.c                      | 16 +++++
>  5 files changed, 84 insertions(+), 6 deletions(-)
> 

Using a mocked socket number seems to be a reasonable mechanism to
achieve the goal. There's certainly other tests that used mocked paths
or results to get a standard result/answer.

Reviewed-by: John Ferlan <jferlan at redhat.com>

John