[Info-vax] VMware

Bob Gezelter gezelter at rlgsc.com
Tue Dec 10 19:27:16 EST 2019


On Tuesday, December 10, 2019 at 1:32:41 PM UTC-5, Grant Taylor wrote:
> On 12/10/19 5:05 AM, Bob Gezelter wrote:
> > However useful VM migration, it is not a functional replacement for 
> > OpenVMS clusters. VM migration allows controlled workload migration, 
> > in the event of an uncontrolled system failure, e.g. complete 
> > power-failure without warning or system destruction. migration will 
> > not have sufficient time to execute a migration.
> 
> I don't completely agree with this.
> 
> VMware has a High Availability mode where the same VM / system image is 
> running concurrently on multiple disparate physical hosts.  One of which 
> will be connected to the outside world.  The other is disconnected and 
> receiving real time updates from the first.  As in VMware is replicating 
> memory, processor, and disk state near real time.  This means that when 
> one physical host falls out of the rack, the other physical host takes 
> over and continues running the VM with the exception that it is now 
> master and the VM is connected to the world.  As such, even established 
> network connections continue on the alternate physical host.
> 
> VMware has, and apparently other hypervisors have, the ability to move 
> running VMs from one host to another host in a manner that is almost 
> unperceptible to clients.  Packets don't drop.  They may have a slight 
> increase in latency /during/ the transition.  But it really looks like a 
> momentary congestion in a router buffer somewhere.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die

Grant,

With all due respect, I want to see the fine-grain details on that implementation. Particularly the part about "packets do not drop". Ensuring granularity of file update is also quite a challenge.

There is a large difference between "rarely are packets lost" and "packets are never lost". Pre-loading other virtual instances and keeping memory state updated them updated is one thing, ensuring mass storage state is something else.

I will not even get into questions like the state of attached non-storage peripherals, e.g. RNGs.

My general advice is to deeply verify the precise nature of the implementation and its limitations before relying on it. 

A while back, I was at an user group event where there was a presentation on VM migration. The speaker made a statement that failover migration would handle all cases. Being from New York City, I inquired about a scenario we had experienced a few years earlier.

A Boeing 767 doing between 150 and 200 knots comes through your machine room window. How long does it take to traverse the 24 inches between front of the cabinet and the back of the cabinet. Even that scenario does not include the fact that the infrastructure connecting one VM host to another has likely been severed before the VM host frame is hit.

- Bob Gezelter, http://www.rlgsc.com



More information about the Info-vax mailing list