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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
