[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 2.0.0.14 (X11/20080508) |
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
- [Qemu-devel] [RFC] More robust migration,
Andre Przywara <=
- Re: [Qemu-devel] [RFC] More robust migration, Anthony Liguori, 2009/02/20
- Re: [Qemu-devel] [RFC] More robust migration, Paul Brook, 2009/02/20
- Re: [Qemu-devel] [RFC] More robust migration, Jamie Lokier, 2009/02/20
- Re: [Qemu-devel] [RFC] More robust migration, Paul Brook, 2009/02/20
- Re: [Qemu-devel] [RFC] More robust migration, Jamie Lokier, 2009/02/22
- Re: [Qemu-devel] [RFC] More robust migration, Paul Brook, 2009/02/23
- Re: [Qemu-devel] [RFC] More robust migration, Jamie Lokier, 2009/02/23
- Re: [Qemu-devel] [RFC] More robust migration, Paul Brook, 2009/02/23
- Re: [Qemu-devel] [RFC] More robust migration, Anthony Liguori, 2009/02/23
- Re: [Qemu-devel] [RFC] More robust migration, Avi Kivity, 2009/02/24