On Mon, Nov 23, 2009 at 09:00:05AM -0600, Anthony Liguori wrote: <snip> > > I think the problem is that you shouldn't be changing the guest visible > state in a stable update of qemu. If you change the guest visible state > in a stable update, then you won't be able to support live migration > between arbitrary stable versions. You can't introduce features without > introducing forward compatibility issues. If you're adding new guest > visible state, you've added a feature. > > This is not a live migration problem, this is a problem with your stable > branch policy.
It is not a feature, because the data was already supposed to be part of the guest visible state, but the implementation was buggy. If the current implementation were the ultimate authority regarding what is a bug and what is a new feature, no software would ever had any bug, everything we call "bug fix" today, would be called "feature". I would agree with you if the ultimate authority regarding expected guest visible state was our implementation. But things aren't that simple: sometimes the definition of "guest visible state" in the implementation is buggy, and we can't just tell users "the feature your guests are using shouldn't be part of the guest visible state, don't use it". -- Eduardo
