On 08/02/2010 05:35 PM, Andre Przywara wrote:
Anthony Liguori wrote:
On 08/02/2010 08:08 AM, Avi Kivity wrote:
I sent a patch to include the cache size when using -cpu host, but
this has been n'acked because the benefit is not clear.
Anthony, why was this NACKed?
I didn't NACK it.
You are right. I am sorry if that created a misunderstanding, I
actually meant: "was not committed".
My concern is that we're still not handling live migration with -cpu
host in any meaningful way. Exposing more details without addressing
live migration is going to increase the likelihood of major failure.
Would you accept a patch simply disabling migration in case -cpu host
was used in the first place?
Yes. The only concern that keeps me from applying it is that it
increases the likelihood of failures with migration. I agree that it's
safer to disable migration until it's fixed properly.
We need to add cpuid information to live migration such that we can
generate a graceful failure during migration. Really, we shouldn't
have taken -cpu host in the first place without this.
Is there already a way to communicate from the target to the source?
This would allow to check for migrate-ability before we transfer any
data. Or should we handle this in a management application?
Send the cpuid fields as part of migration state. Verify they match the
local cpuid fields on the destination side. The destination can then
reject the migration if it can't match those CPUID fields. That's
actually the only way to safely do it today because there's no way for a
management application to query qemu and kvm for the fields that they'll
mask out.
Regards,
Anthony Liguori
Regards,
Andre.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
