From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57355 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrwkM-0006uG-Kg for qemu-devel@nongnu.org; Tue, 22 Feb 2011 13:14:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PrwkL-0005d7-OE for qemu-devel@nongnu.org; Tue, 22 Feb 2011 13:14:02 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:43709) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PrwkL-0005cz-J2 for qemu-devel@nongnu.org; Tue, 22 Feb 2011 13:14:01 -0500 Received: by vws19 with SMTP id 19so3040794vws.4 for ; Tue, 22 Feb 2011 10:14:01 -0800 (PST) Message-ID: <4D63FCE8.5020302@codemonkey.ws> Date: Tue, 22 Feb 2011 12:14:00 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] KVM call minutes for Feb 22 References: <20110222160622.GA7048@redhat.com> <20110222173228.GB28717@playa.tlv.redhat.com> In-Reply-To: <20110222173228.GB28717@playa.tlv.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: "Michael S. Tsirkin" , kvm@vger.kernel.org, qemu-devel@nongnu.org On 02/22/2011 11:32 AM, Alon Levy wrote: > On Tue, Feb 22, 2011 at 06:06:22PM +0200, Michael S. Tsirkin wrote: > >> Looks like Chris will send minutes too, >> so I didn't do much to polish this, >> I didn't realise he's doing it until I had this, so >> here's the braindump: hope it helps. >> >> 1. 0.14 postmortem >> - what went well >> wiki for planning >> testing >> - what can be improved >> rc - cycle could be longer >> >> 2. 0.15 should be end of June >> July 1? >> - features: >> QED >> other? >> virtagent? might be blocked by the rpc issue (discussion followed) >> >> 3. virtagent rpc >> what should virtagent use to talk to the world outside of QEMU? >> Generalize QMP? >> Use an external rpc library? >> Do we want to/can we have virtagent out of process? >> Hard to make well with live migration. >> > Spice had (when migration was bidirectional) an external agent (spice client) > that worked fine with live migration. I agree an external agent makes live > migration more difficult, but I disagree it is a blocker. It did require bidirectional > data exchange with qemu, but how is that a problem? why do all migrations have to > be identical to to-file migrations? > I don't understand well enough exactly how this worked in Spice but there are a few reasons migration is unidirectional. Namely: 1) Round trips during the critical phase add downtime that is proportional to the latency between two nodes. As a rule, if you had bidirectional migration, it needs to minimize the number of round trips to the lowest number possible. Having zero round trips is therefore always desirable. 2) Migrate-to-file doesn't work if bidirectional communication is required. 3) So far, all forms of bidirectional requirement can be/have been satisfied by encapsulating the QEMU migration protocol within another protocol. This use of layering is the preferred approach to extension and is what the current migration code is designed for. Regards, Anthony Liguori