From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZPoX-0000Dy-BL for qemu-devel@nongnu.org; Thu, 24 Oct 2013 14:39:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZPoN-0006tg-Uz for qemu-devel@nongnu.org; Thu, 24 Oct 2013 14:39:21 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:50371 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZPoN-0006sa-JD for qemu-devel@nongnu.org; Thu, 24 Oct 2013 14:39:11 -0400 Message-ID: <5269694B.2030106@kamp.de> Date: Thu, 24 Oct 2013 20:39:07 +0200 From: Peter Lieven MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [RFC] Migration capability negotation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "qemu-devel@nongnu.org" , Paolo Bonzini , quintela@redhat.com Hi, I was thinking that it would be great to have the source and destination during migration negoatiate migration capabilities e.g. something like this: User wants to use a feature e.g. 'zero_blocks'. He switches it to 'on' or maybe a new state 'auto' on the source VM. If the migration is started the source hypervisor sends a set of all desired features. The destination hypervisor answers with a subset of all features it supports and automatically enables them on its side. Depending on the returned subset the source disables all features the destination does not support. This would also allow us also to introduce new features which we would like to enable by default, but we cannot because we do not know if the destination will support it. Is there any way to add this without breaking backwards compability? Comments welcome. Peter