Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

[Eduardo Habkost]

On Mon, Nov 23, 2009 at 03:21:24PM +0100, Paolo Bonzini wrote:
> On 11/23/2009 02:51 PM, Eduardo Habkost wrote:
>> 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".
>
> That's a bit more tricky.  What if the older version doesn't support  
> sound (just making up an example) and you know that you're not using a  
> client that plays sound, but still the sound card is part of the  
> machine?  I think there is no doubt that the migration (or save/restore)  
> should be aborted in that case.

Yes, it's not always that simple. I am thinking about simpler cases
where it is possible to migrate and we know that the missing migration
data won't impact the specific guest OS that is being run.

The pvclock MSRs are an example: if the guest is not using pvclock, not
restoring the MSRs won't make any difference. Strictly speaking, not
migrating them is wrong, but the user may argue that they know it won't
impact their guest OS, and that they want to take the risk. I am not
arguing we should always listen to them, I am just saying that some
users may want that to work.

Also, on the pvclock MSR case (and probably others), any argument
against doing backward migration would also be valid against doing
forward migration when the source process doesn't have the fix yet,
because the pvclock MSRs won't be migrated anyway. Forward migration is
as broken as backward migration, but we don't prevent migration on that
direction.


>
> I would not generalize very much, the problem that Dor posed is very  
> specific and probably quite rare.  However, it's real.
>

-- 
Eduardo