[Qemu-devel] [RFC] More robust migration

[Andre Przywara]

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