From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QleA6-0004Uh-He for qemu-devel@nongnu.org; Tue, 26 Jul 2011 05:42:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QleA4-0004kh-Tn for qemu-devel@nongnu.org; Tue, 26 Jul 2011 05:42:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QleA4-0004kN-Lu for qemu-devel@nongnu.org; Tue, 26 Jul 2011 05:42:48 -0400 Date: Tue, 26 Jul 2011 10:42:38 +0100 From: "Daniel P. Berrange" Message-ID: <20110726094238.GA19481@redhat.com> References: <1309448777-1447-1-git-send-email-pbonzini@redhat.com> <4E2DFAE5.1050304@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E2DFAE5.1050304@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Ryan Harper , Stefan Hajnoczi , quintela@redhat.com, mst@redhat.com, qemu-devel@nongnu.org, Paolo Bonzini On Mon, Jul 25, 2011 at 06:23:17PM -0500, Anthony Liguori wrote: > We also need a way to future proof ourselves. > > == What we can do == > > 1) Add migration capabilities to future proof ourselves. I think > the simplest way this would work is to have a > 'query-migration-capabilities' command that returned a bitmask of > supported migration features. I think we also introduce a > 'set-migration-capabilities' command that can mask some of the > supported features. > > A management tool would query-migration features on the source and > destination, take the intersection of the two masks, and set that > mask on both the source and destination. > > Lack of support for these commands indicates a mask of zero which is > the protocol we offer today. This sounds like a very good idea to me. > 5) .... We could support 50 formats if we wanted to. As long as the > transport is distinct from the serialization and compat routines, it > really doesn't matter. Lets not get too carried away :-) Even just dealing with the different ways libvirt can invoke & manage the migration process gives me ~100 test scenarios to run through for each release of libvirt. The fewer QEMU testing combinations we need to worry about the better, because it quickly explodes with migration as you throw different versions into the mix. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|