[Info-vax] IS everyone waiting?

[johnwallace4 at yahoo.co.uk]

On Wednesday, 26 October 2016 14:30:05 UTC+1, Kerry Main  wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> > Of Phillip Helbig undress to reply via Info-vax
> > Sent: 26-Oct-16 2:03 AM
> > To: info-vax at rbnsn.com
> > Cc: Phillip Helbig undress to reply
> > <helbig at asclothestro.multivax.de>
> > Subject: Re: [Info-vax] IS everyone waiting?
> > 
> > In article <nup4f2$mfb$1 at dont-email.me>, David Froble
> > <davef at tsoft-inc.com> writes:
> > 
> > > Now, maybe I'm going off topic a bit, but, why cannot process
> > (and
> > > login) context be preserved should part of the cluster be
> lost?
> > 
> > Well, a process is running on one CPU.
> > 
> > > Or is that more of something for Non-Stop?
> > 
> > Sure, it's doable somehow, but not with any system as common
> > or more so than VMS.
> > 
> 
> There are 2 scenario's here-
> 
> 1. Planned dynamic process migration to a different system in a
> cluster; 
> 2. Unplanned process migration to a different system (server
> failure etc.) in a cluster;
> 
> Scenario 1 is closer to discussions on fault tolerance systems,
> but given the increase in HW reliability today, scenario 2 is
> likely the biggest benefit to most Customers today.
> 
> Given the right App design, Scenario 2 would allow all sorts of
> additional downtime on servers to be taken without impacting the
> availability of application services.
> 
> Notwithstanding it's still a good feature, note that VMware can
> only do dynamic system OS migration from one server to another.
> It can do this because the entire VM OS is actually just a file.
> All it does is provide pointers to the file on a different OS.
> 
> Regards,
> 
> Kerry Main
> Kerry dot main at starkgaming dot com

As far as I'm aware, vMotion etc does the "planned" one. Not
so much the 'unplanned' one. One reason is that system memory
changes are quite hard for persistent storage to keep up with,
and yet a persistent copy of system memory is exactly what
vMotion etc need. 

Getting an up to date memory image into persistent storage
gets easier if you can do it in stages, but to do it in
stages you basically have to be able to plan it a little
ahead of time. There might, just might, even be some visible
performance impact on some time-critical systems while the
memory save-to-'disk' is going on.

Now, take this a little further and see if you can work
out how well it will work on an edge case system with a
lot of memory write traffic compared to run of the mill
systems. 

Details matter, sometimes. Sometimes, they matter *a lot*.

Further reading: see e.g.
http://www.opvizor.com/vmware-vmotion-how-it-works-part-1-introduction/