On Mon, Nov 23, 2009 at 01:25:32PM +0100, Juan Quintela wrote: > Gleb Natapov <g...@redhat.com> 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.