Questions about using qemuProcess API within a libvirt test
Hello,
I am working on implementing libvirt test cases for the hypervisor-cpu-compare
and -baseline commands. Ideally, I would like to take advantage of the
qemuProcess API to spin up a QEMU instance and run these commands to test real
data queried from the hypervisor. However, I am having issues with my libvirt
tests communicating with a QEMU instance. The API can successfully spin an
instance, but no commands can be sent to QEMU -- not even the qmp_capabilities
handshake. The test case hangs forever with no indication that something went
wrong.
The hang occurs specifically within the qemuProcessQMPLaunch phase of the
qemuProcessQMPStart function. Eventually the libvirt API will get to
qemuMonitorSend, and at this loop...
while (!mon->msg->finished) {
if (virCondWait(&mon->notify, &mon->parent.lock) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Unable to wait on monitor condition"));
goto cleanup;
}
}
...the program will hang at conditional wait. I kept the QEMU instance alive
after killing my test and connected to the monitor socket that was still
lingering. The qmp_capabilities command was never sent, thus leading me to
believe that the libvirt tests cannot communicate with a QEMU instance.
As s390x is currently the only arch to have implemented these commands, I
believe it would be beneficial to have an easy way to test both the expected
QEMU response and libvirt parsing within a single test case if/when other archs
decide to implement these commands.
I'd like to ask two questions:
1: does it make sense for libvirt tests to communicate with an external binary
(specifically QEMU)?
2: if so, is there some sort of conflict between a libvirt test and a QEMU
binary? I afraid to say that I am at a loss how to repair this or perhaps how
to use the API properly.
I appreciate anyone's help with looking into this.
Note: in case I am not clear, by "libvirt test" I am referring to a test
implemented in the tests directory of the libvirt project.
--
Respectfully,
- Collin Walling