On Mon, Nov 23, 2009 at 08:53:54AM -0600, Anthony Liguori wrote: > Eduardo Habkost wrote: >>>>> 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". >> > > This could be addressed with a "force" migration feature. That said, I > don't believe that the overwhelming majority of users are in a position > to determine whether they can safely migrate to an older version. > > Regards, > > Anthony Liguori
It's very easy: if their guest runs fine on the old qemu, it should be safe to migrate there. -- MST
