[Info-vax] VMware

[Grant Taylor]

On 12/10/19 5:27 PM, Bob Gezelter wrote:
> With all due respect, I want to see the fine-grain details on 
> that implementation.

Please see my reply from ~ 7:35.  (Adjust hour accordingly for your time 
zone.)

I think that's about as granular as I can get without going and looking 
things up.

I have no problem with you wanting to see the fine-grain details.  I 
asked very similar questions 10+ years ago.  Hence why I have the 
understanding that I do.  Also why it's now only a high level detail.

> Particularly the part about "packets do not drop".

I've routinely moved VMs between hosts without dropping packets.  I do 
see latency at the epoch of the transition increase momentarily (usually 
just one packet).  But the packet does make it through and is not dropped.

Frequently latency is something like this:

1–3 ms
1–3 ms
1–3 ms
9–12 ms
1–3 ms
1–3 ms
1–3 ms

No packet drop.

TCP sessions continue without retransmissions.

> Ensuring granularity of file update is also quite a challenge.

Why?  (Please see my other message about what happens.)

> 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.

All hosts in the cluster have access to the same storage.  So anything 
written on one host is readable by other hosts.  Part of the migration 
ensures that cached data is synced to disk and / or copied as part of 
the memory for the system.

So there's no "mass storage state" to keep in sync because it is the 
same back end storage.

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

Those would be the types of things that would prevent migration between 
hosts.

Though, I think that VMware has an option to allow USB peripherals to be 
used across the network.

If not VMware, there are other OS level solutions to allow some 
peripherals to be used across the network.

I've personally used remote (TCP based) serial ports for fax servers. 
The modem is physically connected to a network attached DigiBoard (or 
the likes) and the VM is free to move from host to host to host because 
it's TCP connection to the serial port is still in tact.

Given that faxing is time sensitive serial audio / data (depending on 
the modem) there may be an issue with the momentary increased latency. 
I don't know if that would ride through a migration or if it would rely 
on error detection and correction in the modem / fax level.

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

I think that's a wonderful idea.

> 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.

~chuckle~

Absolutes are usually a problem in one way or another.  ;-)

> 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.

I think that's a valid question.  I think it's an EXTREMELY ATYPICAL 
failure scenario.  But it is decidedly within the "all cases" absolute 
the speaker set themselves up for.

I think that would be very difficult to protect against.

I would question, what about a data center in an adjacent building that 
you can extend the LAN / SAN / etc. into.  Though it could also 
experience a similar problem (fate sharing).

When you start talking about failures that can take out multiple 
buildings in close proximity to each other, you REALLY need an EXTREMELY 
robust solution.

I do think that VMware has some solutions that can work over extended 
distances.



-- 
Grant. . . .
unix || die