From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Lalancette Subject: Re: [PATCH]: Add a "migrate_incoming" monitor option Date: Fri, 01 Aug 2008 11:04:13 +0200 Message-ID: <4892D18D.3060706@redhat.com> References: <4891D14B.9010304@redhat.com> <4891F60F.9060200@codemonkey.ws> <20080801084234.GD23993@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm-devel To: "Daniel P. Berrange" Return-path: Received: from mx1.redhat.com ([66.187.233.31]:36805 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752323AbYHAJFv (ORCPT ); Fri, 1 Aug 2008 05:05:51 -0400 In-Reply-To: <20080801084234.GD23993@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Daniel P. Berrange wrote: > An accept trick only handles the TCP case though. I know this was Chris' > example that we're currently using, but we intend to switch to passing > an open file descriptor instead, and proxying the data via a secure > channel instead of the plain tcp, or builtin SSH tunnelling. > > With an open FD we'll need another way - I guess just registering a > event on POLLIN might do the trick. It seems to me that just having > an explicit migrate incoming monitor command would be simpler than having > to code different triggers to implement 'nowait' for each transport > we have. I just finished a patch to do the "nowait" for tcp as suggested by Anthony, and it was actually far less code then I feared. It just needed a little re-factoring of the migrate_incoming_tcp() function. I'll be posting that in a couple of minutes. Given how this code worked out, doing a "nowait" for the fd style is really no big deal. Both ways (explicit monitor command and "nowait") seem to have their benefits; the monitor command has the benefit of being more flexible, while the nowait has the benefit of being similar to already existing Qemu commands. My preference is for the monitor command since it seems a little more natural for a management tool, but the nowait is clearly an option as well. I'll also post a cleanup patch with Dan's suggestion for the monitor patch, so both implementations will be available. Chris Lalancette