On 04/23/2010 09:21 AM, Daniel P. Berrange wrote:
Say libvirt is running a 'offline core dump' operation. This consists of
us invoking
stop
migrate exec:cat> foo.dump
cont
I don't want other debug commands accidentally being issued in between
these steps. These 3 commands are in essence considered transactional
block. Internally our locking model ensures that no other APIs can be
invoked in this monitor connection during this sequence. Thus if someone
uses the libvirt debug API to issue a monitor command, thus command will
be blocked until the last 'cont' command is issued here. This provides us
a known command ordering in the logs.
Ah, so what'd I'd suggest is that you still use two monitors but that
you use the same locking for both. The reason a second monitor is
useful is that you can allow different event masks to be setup on the
second monitor which I think a QMP client will expect.
I don't see any trouble with respect to command ordering here. libvirt
is ultimately the one sending commands to monitor. You know which one
was sent and which one completed in what order.
With a single monitor connection, libvirt's current
locking model for the monitor ensures that QMP monitor commands are
reliably
serialized onto the wire, giving unambiguous behaviour.
Except that libvirt doesn't know what the side effects of the debug
commands are so it's intrinsically ambiguous :-)
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.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list