[libvirt] [PATCH v3 2/4] qemu: support passing pre-opened UNIX socket listen FD
Eric Blake
eblake at redhat.com
Thu May 24 21:50:36 UTC 2018
On 05/17/2018 08: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.
>
> +++ b/tests/qemuxml2argvmock.c
> +int
> +qemuOpenChrChardevUNIXSocket(const virDomainChrSourceDef *dev ATTRIBUTE_UNUSED)
> +
> +{
> + /* We need to return an FD number for a UNIX listener socket,
> + * which will be given to QEMU via a CLI arg. We need a fixed
> + * number to get stable tests. This is obviously not a real
> + * FD number, so when virCommand closes the FD in the parent
> + * it will get EINVAL, but that's (hopefully) not going to
> + * be a problem....
> + */
> + return 1729;
Is it worth asserting that 1729 is not an open fd (perhaps by
fcntl(1729, F_GETFD) == -1) because of something strange in the test
environment?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
More information about the libvir-list
mailing list