I think the first order of business here would be to define what it is
we would like to see VM support in the area of "guest migration". I
think we could all agree on the following requirements:
1) VM needs the capability to migrate running guest operating systems
from one LPAR or physical processor to another LPAR or physical
processor, *with no loss of functionality by the guest*.
2) In order to achieve such a capability, certain guest virtual machine
configuration setups might need to be done beforehand, e.g., each guest
virtual machine CP definition in each system must be identical.
I think this is what we are after, correct?
David Boyes wrote:
[snip of some interesting implementation ideas....]
So most likely you would need something like PPRC over ISFC to build a
copy of the working set at the receiving side. The actual delay would
be just packing up the stuff that changed very recently, and restore
that on the other side.
To do this efficiently, you'd need something like the above NUMA idea,
I'd think. But, this is essentially what VMotion does, and it seems to
work pretty well.
One way of keep disk images in sync between the two systems would be to
create two identical sets of DASD volumes, at different real addresses,
with identical sets of minidisks (holding exactly the same file systems
(CMS, Linux, etc.) in the same states) on them at system IPL time. One
set we can term the "hot" volumes that will be used by the guests in
their normal mode of operation and the other set the "standby" set.
Then, as each gust is brought up and starts to do i/o to it's "hot set"
of minidisks (i.e., the minidisks that are defined in it's CP directory
entry). CP would duplicate all write operations to the base minidisks on
the hot volumes to the same minidisks on the "standby volumes, thus
keeping each in sync. This is very easily done with a CP exit, and in
fact, I have such an exit here. Contact me off list if you'd like more
details.
Since we would now have a situation in which we always have two sets of
DASD that are kept in sync, a guest migration comes down to getting all
of the active data (page frames, network connections, etc.) moved over;
the data on DASD would already be there and usable. This might make the
migration updates to CP more manageable......
This mailing list really needs a virtual whiteboard facility...8-)
That's an excellent idea....how could we pull that off? ;-)
DJ
-- db
