Re: [libvirt] [RFC] make virDomainQemuMonitorCommand work in any libvirt state

On 17.10.2016 20:46, Nikolay Shirokovskiy wrote: > Hi, all. > > We would like to use virDomainQemuMonitorCommand to query qemu independently of > libvirt state. Currenly it is not possible. This API call takes job condition > just like any other call and thus is unavailable on any lengthy(or stucked) > synchronous job. > > I've already posted this question in list, just failed to find the reference. > Somebody suggested to use proxy (and even an implementation) in between qemu > and libvirt that can inject commands to qemu and filter replies. It is not > really convinient. This way test setups will be different from production and > we can not investigate problems in production environment. > > I'd like to drop acquiring job condition in the call as this function does not > deal with libvirt state (except for the taint but is is ok, we will not mess > things up here). But this is not enough, we need to make qemu monitor deal with > many qemu commands simultaneously. Looks like it is quite a big change for > test/debug case. But I guess eventually normal user cases can get benefits too > from this monitor changes. For example all query API calls that query qemu > directly can be changed to not to wait for some synchronous job > finishing.(qemuDomainGetBlockJobInfo for example). IIRC the last time I looked into this the problem was not on libvirt side. QEMU's monitor was unable to process multiple commands at once. But maybe that's no longer the case, I don't know.

However, what I think we should do is to turn our jobs into sort of RW locks. That is - we could allow multiple QUERY jobs to happen simultaneously and leave MODIFY jobs to be exclusive. I think dropping BeginJob() from an API is a no go as it will definitely bite us in the future. Unfortunately, I have no idea what my suggestion would look like in terms of the code. How difficult it would be to implement it (and whether monitor code is prepared for that).