[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