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

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.

>> 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.