[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [RFC] More robust migration

From: Andre Przywara
Subject: [Qemu-devel] [RFC] More robust migration
Date: Fri, 20 Feb 2009 15:36:08 +0100
User-agent: Thunderbird (X11/20080508)


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!


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]