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

[Anthony Liguori]

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