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

[Anthony Liguori]

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