qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: Re: Live migration protocol, device features, ABIs and other beasts
Date: Tue, 24 Nov 2009 16:26:49 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Mon, Nov 23, 2009 at 09:12:15AM -0600, Anthony Liguori wrote:
> Eduardo Habkost wrote:
>> 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.
>
> Once you start dealing with issues of risk vs. benefit, it's a policy  
> and belongs in the management layer.
> 
> We don't make risk vs. benefit assessments in qemu.  We defer those  
> types of decisions.
>
> Today, we only succeed migration when we know it will be successful.  We  
> could allow a management tool to override this check such that it could  
> implement such a policy.  But that's a really dangerous option to offer.
> 
>> 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.
>>   
>
> A bug that is visible to a guest is no longer a bug, but a feature that  
> has to be supported for as long as that release is supported.  If we  
> feel that it's too dangerous of a bug, then we need to fail gracefully  
> and refuse to load that state on any other system forcing a proper  
> shutdown/startup for migration to a new version of qemu.
>
> For the purposes of compatibility, it is something that we have to  
> preserve.  In this case, you're introducing two MSRs that are readable  
> and writable by a guest.  If you migrate all of the sudden you lose that  
> MSRs content.  You cannot have live migration cause an MSR to disappear  
> regardless of what the purpose of that MSR is.
>
> Regards,
>
> Anthony Liguori

Same with having MSRs appear, surely?

-- 
MST




reply via email to

[Prev in Thread] Current Thread [Next in Thread]