From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH]: Add a "migrate_incoming" monitor option Date: Thu, 31 Jul 2008 12:27:43 -0500 Message-ID: <4891F60F.9060200@codemonkey.ws> References: <4891D14B.9010304@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Chris Lalancette Return-path: Received: from wr-out-0506.google.com ([64.233.184.239]:33684 "EHLO wr-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752066AbYGaR2R (ORCPT ); Thu, 31 Jul 2008 13:28:17 -0400 Received: by wr-out-0506.google.com with SMTP id 69so514415wri.5 for ; Thu, 31 Jul 2008 10:28:16 -0700 (PDT) In-Reply-To: <4891D14B.9010304@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Chris Lalancette wrote: > We've been trying to plumb libvirt to do KVM migration. One of the stumbling > blocks we are running into, however, is that libvirt expects to be able to use > the Qemu monitor both before and after migration has taken place, on both the > source and destination nodes. After migration has taken place is no problem; we > return to the main qemu select() loop, and we can run monitor commands. > However, before migration, on the destination side, when we start qemu with a > command-line like: > > qemu-kvm -M pc -S blah blah -incoming tcp://0:4444 > > we can't run any monitor commands since the migration code is synchronously > waiting for an incoming tcp connection. To get around this, the following patch > adds a new monitor command called "migrate_incoming"; it takes all of the same > parameters as the command-line option, but just starts it later. To make sure > it is safe, you actually have to start with "-incoming monitor"; if you run it > without that, it will just spit an error at you. So with this in place, libvirt > can do the equivalent of: > > qemu-kvm -M pc -S blah blah -incoming monitor > I think adding a 'nowait' parameter to migration would make more sense than introducing a monitor command. So: qemu-kvm -M pc -S blah blah -incoming tcp://0:4444,nowait From an implementation perspective, it's just a matter of setting a callback for the accept fd I imagine. Regards, Anthony Liguori > (qemu) info cpus > ...other commands > (qemu) migrate_incoming tcp://0:4444 > ...wait for migration to start, and then complete > (qemu) info block > ...etc. > > Signed-off-by: Chris Lalancette >