|Subject:||Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts|
|Date:||Sun, 22 Nov 2009 20:17:46 -0600|
|User-agent:||Thunderbird 126.96.36.199 (X11/20090825)|
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.
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.
Regards, Anthony Liguori
|[Prev in Thread]||Current Thread||[Next in Thread]|