On Sat, Apr 2, 2011 at 3:03 PM, Shriram Rajagopalan <rshriram@xxxxxxxxx> wrote:
> I agree with George's suggestion on MORE_CHECKPOINTS, for backwards
> wrt live migration.
It turns out that there actually isn't (I don't believe) a
compatibility issue with live migration. the issue I was seeing was
due to a modification I'd made to libxc to get the XenServer / XCP
toolstack (xapi) working with Xen 4.1. As long as you're using only
open-source tools, you should still be able to migrate 4.0->4.1 --
there will just be a short delay while the toolstack waits for more
> But for HA, it doest make much sense if a user is able
> to do HA only
> one way and cannot failback. This is not a upgrade scenario. So, that would
> require some
> exception to be thrown when a version incompatibility is detected. IMO, its
> better to
> let the user handle this limitation than letting him/her do the N->N+1 HA
> and then finding out
> that they cannot failback.
Well, you can't actually do HA while one of the two hosts is being
rebooted anyway. :-) So I think with backwards compatibility, you
could do it with 3 hosts: run on A with B as a fallback while
upgrading C, then run on A with C as a fallback while upgrading B,
then migrate to C (or just pull the plug on A and let it fall back
normally) and run on C with B as a fallback while upgrading A.
Without backwards compatibility, I think you could do it with 4 (so
you always have 2 hosts of a given version).
Or you could just run it in non-HA mode while the hosts are upgraded
serially; for XenServer / XCP, it normally wouldn't take more than 20
minutes to do both, after which point you could turn on HA again.
Xen-devel mailing list