[libvirt] [Qemu-devel] Re: Libvirt debug API

Avi Kivity avi at redhat.com
Sun Apr 25 14:50:52 UTC 2010

On 04/23/2010 09:33 PM, Anthony Liguori wrote:
>> This is a different ambiguity, about the semantic results of the 
>> commands,
>> where as I'm refering to the execution order. If I look at a libvirt log
>> file and see a set of JSON commands logged, I want to know that this 
>> ordering
>> from the logs, was indeed the same as order in which qemu processed 
>> them. If
>> you have two separate monitor connection you can't be sure of the 
>> order of
>> execution. It is key for our bug troubleshooting that given a libvirt 
>> log
>> file, we can replay the JSON commands again and get the same results. 
>> Two
>> monitor connections is just increasing complexity of code without any
>> tangible benefit.
> I think you're assuming direct access to the second monitor?  I'm not 
> suggesting that.  I'm suggesting that libvirt is still the one 
> submitting commands to the second monitor and that it submits those 
> commands in lock step.

What about protocol extensions?  For instance, pretend libvirt doesn't 
support async messages, what would it do when it receives one from the 
user's monitor?

error compiling committee.c: too many arguments to function

More information about the libvir-list mailing list