Excerpts from Anthony Liguori's message of Mon Nov 23 00:17:46 -0200 2009: > 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.
I was going to suggest that. The current section system would be a good candidate for a "capability" system. e.g. instead of adding new data to the "cpu" section and increasing its version number, you add a "cpu.pvclock-msrs" section that contains the new data. This way, if a vendor backports the fix, it doesn't mess up with the section version numbers. We could improve the API to make it easier to do, or maybe even improve the protocol/format to make the "subsection" representation more compact. Either way, my point is that using names to track new capabilities sounds better than having to agree on capability bits. > > >> Migration needs to be conservative. There should be only two possible > >> outcomes: 1) a successful live migration or 2) graceful failure with the > >> source VM still running correctly. Silently ignoring things that could > >> affect the guests behavior means that it's possible that after failure, > >> the guest will fail in an unexpected way. > > > > It's up to the source to decide what information is extra. For > > example, the state of a RNG emulation is nice-to-have, but as long as > > it is initialized from another random source on the destination you > > shouldn't care. > > We only migrate things that are guest visible. Everything else is left > to the user to configure. We wouldn't migrate the state of a RNG > emulation provided that it doesn't have an impact on the guest. > > By definition, anything that is guest visible is important because it > affects the guest's behavior. Right, but I wouldn't be surprised if a user complains that "I know that my guest don't use that VM feature, so I want to be able to migrate to an older version anyway". -- Eduardo