From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [Qemu-devel] [RFC] New thread for the VM migration Date: Mon, 18 Jul 2011 09:08:16 +0200 Message-ID: References: <1447945249.1317755.1310627692984.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <4E1EAA72.1060103@redhat.com> <4E1EE183.5050100@codemonkey.ws> <4E1EE1F2.5020801@redhat.com> <4E1F0EC2.1050408@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Umesh Deshpande , qemu-devel@nongnu.org, kvm@vger.kernel.org To: quintela@redhat.com Return-path: Received: from mx1.redhat.com ([209.132.183.28]:8688 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750745Ab1GRHIW (ORCPT ); Mon, 18 Jul 2011 03:08:22 -0400 In-Reply-To: (Juan Quintela's message of "Thu, 14 Jul 2011 17:52:17 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Juan Quintela writes: [...] > I have think a little bit about hotplug & migration, and haven't arraive > to a nice solution. > > - Disabling hotplug/unplug during migration: easy to do. But it is not > exactly user friendly (we are here). > > - Allowing hotplug during migration. Solutions: > * allow the transfer of hotplug events over the migration protocol > (make it even more complicated, but not too much. The big problem is > if the hotplug succeeds on the source but not the destination, ...) > * migrate the device list in stage 3: it fixes the hotplug problem > nicely, but it makes the interesting problem that after migrating > all the ram, we can find "interesting" problems like: disk not > readable, etc. Not funny. > * > > As far as I can see, if we sent the device list 1st, we can create the > full machine at destination, but hotplug is "interesting" to manage. > Sending the device list late, solve hotplug, but allows errors after > migrating all memory (also known as, why don't you told me *sooner*). I figure the errors relevant here happen in device backends (host parts) mostly. Maybe updating just backends is easier than full device hot plug. Configure backends before migrating memory, to catch errors. Reconfigure backends afterwards for hot plug[*]. Then build machine. You still get errors from frontends (device models) after migrating memory, but they should be rare. [...] [*] You could do it "in the middle" to catch errors as early as possible, but I doubt it's worth the trouble.