John Byrne wrote:
>There are various differences between x86 CPU types that
I believe would cause a guest to fail after being migrated. Are there >checks
in the migration code to prevent this from happening? Does it check for an
"incompatible CPU" and fail early, leaving the >guest running on
the source host? If there is a check, what is its nature? (Exact match of CPU
type/rev or something based on >CPU-features?)
>Thanks,
>John Byrne
No. no checks for CPU type in migration code. And since the
RAM image itself is being copied, there are certainly different
Problems created.
But it's even more complicated than that: the question of
whether or not the migrated guest will fail or not depends on the CURRENT RAM
image, and it may succeed at one point and fail in another one. It all depends
on the current state.
Here is an interesting example I ran into:
I created my guest on my Athlon and tried to migrate it to
my laptop running a Pentium M. The guest failed.
When I tried the opposite, creating it on my laptop and
migrating it to my Athlon, it worked… Not only that, but now, after
being forged in the flamed of the Pentium M, I could migrate it BACK from the
Athlon to the laptop…then to an Opteron… That was fun. It can
actually function like a roaming guestJ
One problem is that OSs
usually gather information on the system they are running, on all the features the
CPU offers them.
What if one or more of the features is not supported on the
target host? You think it will crash?
NOT necessarily. It won't crash if there's currently no
running code on the guest that uses that feature.
I believe It will also be a problem if some code that USES
such a feature is ON the guest RAM image, but for some reason is not
Currently running, until a user dose something…this
could lead to seemingly unexplained crashes.
I am also interested
in future compilations/executions on the migrated OS…
It can be
affected too…
NOW, having
said that… completely preventing migration between CPUS that are not 100%
compatible may not be a good idea…
after all…you may KNOW that the current configuration will work on the
other machine (or you may know it was migrated from there
In the first
place), and you may need to do a hardware upgrade with no downtime… no
reason to prevent this…
I discovered
that as long as you create the guest on the machine with the LEAST amount of
features among the ones it may
Be migrated
to (the one that has NO feature the other ones don't have) , the migration
seems to work fine in every direction.
