qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [libvirt] Libvirt debug API
Date: Mon, 26 Apr 2010 08:14:08 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 04/25/2010 09:50 AM, Avi Kivity wrote:
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?

Protocol extensions could not be supported in this model. I agree, that's unfortunate.

Regards,

Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]