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

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?