From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5NhO-0003OL-Cw for qemu-devel@nongnu.org; Fri, 23 Apr 2010 14:33:58 -0400 Received: from [140.186.70.92] (port=34461 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5NhM-0003Nk-SC for qemu-devel@nongnu.org; Fri, 23 Apr 2010 14:33:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5NhL-00080E-4m for qemu-devel@nongnu.org; Fri, 23 Apr 2010 14:33:56 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:61602) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5NhK-000806-VM for qemu-devel@nongnu.org; Fri, 23 Apr 2010 14:33:55 -0400 Received: by pwi6 with SMTP id 6so6527255pwi.4 for ; Fri, 23 Apr 2010 11:33:54 -0700 (PDT) Message-ID: <4BD1E80C.30402@codemonkey.ws> Date: Fri, 23 Apr 2010 13:33:48 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Libvirt debug API References: <4BBF2E93.3020508@redhat.com> <20100409142717.GA11875@redhat.com> <4BD09947.7060207@codemonkey.ws> <20100423102831.GA17700@redhat.com> <4BD1A361.6040702@codemonkey.ws> <20100423142158.GD17700@redhat.com> In-Reply-To: <20100423142158.GD17700@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Libvirt , Jiri Denemark , Chris Lalancette , qemu-devel@nongnu.org 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