[Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

[Gleb Natapov]

On Mon, Nov 23, 2009 at 01:25:32PM +0100, Juan Quintela wrote:
> Gleb Natapov <address@hidden> wrote:
> > On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
> >> Paolo Bonzini wrote:
> >> >
> >> >>I don't see how this fixes anything. If you used feature bits, how do
> >> >>you migrate from a version that has a feature bit that an older version
> >> >>doesn't know about? Do you just ignore it?
> >> >
> >> >I'd go with chunk instead of feature bits, specifying them like in
> >> >the PNG specification:
> >> 
> >> You mean, each device would have multiple sections?  We already use
> >> chunks for each device state.
> >> 
> > Each device can send device info in multiple formats (each format with
> > its own ID) and destination will choose the one it supports.
> 
> RAM anyone?  You send 1GB of info in different formats, just in case :)
> 
RAM is migrated very differently from devices. No need to extend this
for RAM.

> In this case, I think that the only two realistic solutions are to
> increase negotiation during migration:
> 
> - source -> target: I can save this devices with this versions:
>    "cpu" 10 - 12
>    "apic" 3
>    "ide" 2-4
>    "virtio-net" 5-10
>    ....
> - target -> source:
>    * I don't support "virtio-net" at all -> failed migration
>    * send it as:
>       "cpu" 11
>       "apic" 3
>       "ide" 2
>       "virtio-net" 10
>      thankyou very much :)
> 
> The other (more simple solution) is:
> 
> - source -> target:
>    my machine types are: pc-0.10, pc-0.11
>    my devices are: "cpu", "apic", "ide", "virtio-net"
> - target-> source
>    * I dont' have "virtio-net" -> fail, or
>    * send it as pc-0.10, please
> 
Yes, I proposed to send device state in multiple formats specifically to
prevent negotiation step, but may be proper negotiation is not so
bad/complex after all.

> My problem implementing optional features/sections/... is not the
> savevm/VMState bits.  At the end, implementing that is easy.  What is
> more dificult is once that a device have 5 features, what are the valid
> combinations.  i.e. if you have pci and msix features, msix requires
> pci.  In this case, the dependency is trivial, but in others that
> hasen't to be so obvious.
It doesn't matter what device support and how it is configured. This can
be handled by each device separately. i.e if destination detects that
source had MSIX enabled for the device but destination hasn't it will
signal an error.

> 
> Having subversions for downstream is a different problem that needs to
> be fixed.
> 
> Later, Juan.

--
                        Gleb.