jd wrote:
Hi
For migration to work, it is recommended to start the VM with exact same params as the original VM. Can some one clarify the minimum set that should be the same.. while if others like VNC port Or default bridge can be different. (as the target machine may have vnc port already used.)
Anything that affects the hardware exposed to the guest must be the
same. -vnc, -net tap, -monitor, etc. have no effect on the hardware
exposed to the guest so they can be modified.
Also, if there are any compatibility checks for migration that needed to be
done for predicting successful migration
Note that a primary design goal of migration is that failure will never
result in a lost VM so it is generally safe to try a migration even if
there's a chance it may fail.
-- KVM version ? Same... similar.. any other way to find if they are
'compatible' ? (As KVM is released frequently)
The format should be backwards compatible so version checking isn't
necessary.
-- Processor same / similar ? Do we have a good compatibility matrix
somewhere ? I am assuming that there is nothing specific to KVM but would like
to confirm.
We do our best to expose only a common subset of features for guests.
Practically speaking, it's a trade-off. It is only "safe" to migrate to
absolutely identical CPUs otherwise you risk the guest miscalibrating
the TSC.
In general, modern Linux guests can detect the TSC screwing up and as
long as your going from a slower to faster system, it should be okay (or
perhaps vice versa).
-- Memory availability : How to compute availability of "enough" memory ?
Free physical memory ? Or some weight on available virtual memory/swap ? weave in some
knowledge of ballooning details.
KVM supports memory overcommit so it simplifies and complicates things.
A migration should always succeed regardless of memory on the system but
performance may suffer because of swapping. So choosing the best
migration target will have to take into account available free memory,
how many VMs are on the system already (the potential memory use for the
future), etc.
Regards,
Anthony Liguori
Any other checks ?
Thanks
/Jd
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
