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

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



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


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