On Wed, Oct 19, 2016 at 09:50:37AM +0800, Michal Privoznik wrote: > 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. That is still the case. If you send a command while something else is running QEMU will not process it until the previous command is completed. There was a proposal last week to address this in QEMU, but it is not going to be fully fixed anytime soon. > 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). Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list