On 08/03/2010 02:38 AM, Anthony Liguori wrote:
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?
Since this is determined at startup time, it should be done by
management. There's no point in starting a live migration that we know
will fail.
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.
I agree with that, as a safety check.
Note it can be determined even earlier, if qemu warns/fails on masked
features:
qemu -cpu qemu64,+this,-that,strict
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.
That needs to part of the qemu capabiltities megapatch. Supporting
POPCNT isn't very different from supporting cache=unsafe from the
management point of view.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
