From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaWS8-0006FZ-6k for qemu-devel@nongnu.org; Fri, 20 Feb 2009 09:34:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaWS4-0006Df-0L for qemu-devel@nongnu.org; Fri, 20 Feb 2009 09:34:07 -0500 Received: from [199.232.76.173] (port=59847 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaWS3-0006DF-OO for qemu-devel@nongnu.org; Fri, 20 Feb 2009 09:34:03 -0500 Received: from wa4ehsobe003.messaging.microsoft.com ([216.32.181.13]:48732 helo=WA4EHSOBE003.bigfish.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.60) (envelope-from ) id 1LaWS3-0007Ws-B8 for qemu-devel@nongnu.org; Fri, 20 Feb 2009 09:34:03 -0500 Received: from mail3-wa4 (localhost.localdomain [127.0.0.1]) by mail3-wa4-R.bigfish.com (Postfix) with ESMTP id 73BFF4A810A for ; Fri, 20 Feb 2009 14:34:01 +0000 (UTC) Received: from svlb1extmailp02.amd.com (unknown [139.95.251.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail3-wa4.bigfish.com (Postfix) with ESMTP id BFD59B98055 for ; Fri, 20 Feb 2009 14:33:59 +0000 (UTC) Received: from svlb1twp01.amd.com ([139.95.250.34]) by svlb1extmailp02.amd.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id n1KEXsON004328 for ; Fri, 20 Feb 2009 06:33:57 -0800 Received: from SSVLEXBH2.amd.com (ssvlexbh2.amd.com [139.95.53.183]) by svlb1twp01.amd.com (Tumbleweed MailGate 3.5.1) with ESMTP id 2583488493D for ; Fri, 20 Feb 2009 06:33:39 -0800 (PST) Message-ID: <499EBFD8.50307@amd.com> Date: Fri, 20 Feb 2009 15:36:08 +0100 From: Andre Przywara MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [RFC] More robust migration Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, after fiddling around with migration (and the data dumped into the stream) I found the current concept possesses some shortcomings. I am interested in your opinions whether it is worth to implement a new improved format. Issues I would like to address: 1. Transfer configuration data. Currently there is no VM configuration data transferred with the stream. One has to start QEMU/KVM with the _exact_ same parameters on the other side to allow migration. If there would be a pseudo-device (transferred first) holding these parameters (and other runtime dependent stuff like kvm_enabled()) this would ease migration a lot. 2. Introduce a length field to the header of each device. This would allow to skip unknown (or unwanted) devices. I know this imposes a bit of a challenge, because the length is not always known in advance, but one could overcome this (by using the buffer to patch in the length later for instance). 3. Make the device versioning really bulletproof. Currently some devices dump different data depending on runtime (or better time-of-creation) state (for instance hw/i8254.c: if (s->irq_timer)...). Another example is the (x86?) CPU state, which differs with KVM en/disabled. Some devices even dump host system dependent structures (like struct vecio in virtio-blk.c). Also one could create some kind of (limited) upward compatibility, so older QEMU versions ignore additional, but optional fields in a device state (similar to the ext2 compatibility scheme). Maybe this could be done by an external converter program. 4. Allow optional devices. Some devices are always started (like HPET), although they don't need to be used by the OS. If one migrates such a guest from say KVM-83 to KVM-81, it will fail, because KVM-81 does not support HPET. One could migrate the device only if it has been used. In general I would like to know whether QEMU migration is intended to be used in such a flexible manner or whether the requirement of the exact same software version on both side is not a limitation in everyday use. Awaiting your comments! Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 277-4917 ----to satisfy European Law for business letters: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632