On Jan 23, 2007, at 11:37 AM, Dave Jones wrote:
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?
There's also an issue of WHAT needs to be available 24x7.
For a single guest system image to be available implies serialization
of the entire state of the guest, including memory and device state.
That's pretty hard and imposes lots of architectural limitations on
the guests. If you want to do it for unplanned migration, you're
also talking about a *lot* of bandwidth to keep the hot memory images
in sync (the model I'm thinking of here is VMware's vmotion) at all
times, and that will impose a significant performance penalty on the
images.
On the other hand, if all you need is *service* availability, well,
Linux-HA is probably adequate (as would be something like Symantec's
VCS (which may even be available for System z)). In that case you
basically end up with shared DASD (and IO fencing) between the
systems, a virtual IP address that you can move, and then, say,
agents to start up/shut down a database (assuming that a database
instance is your service) on a new node if it faults on the first
node, acquire disk groups, mount volumes, etc.
SCSI-3 persistent reservations give you what you need to do IO
fencing in a FC environment. I would think that you could play
similar games with shared ECKD, although I don't know if Linux is
aware of how to do that.
In short, I'd say you're much better off providing service rather
than image availability, as that's in many ways a much, much easier
problem.
Adam
