[Info-vax] VMware

[Grant Taylor]

On 12/10/19 4:22 PM, Craig A. Berry wrote:
> So there is a perfect up-to-date mirror in hard real time of all of 
> the states of all of the devices and all these different states are 
> coordinated with each other?

For supported (read: virtualized / emulated) devices, yes.

What is state, other than the contents of memory and CPU registers 
(which are themselves another memory)?

Said state is replicated from the primary host to the secondary host in 
very close to real time.  When a memory write happens on one system, the 
same write (or delta) is pushed to the secondary system.

> For example, if I'm in the middle of changing my password when one 
> of these transitions happens, the state of this process on the new 
> instance looks exactly like it was on the old one regardless of whether 
> the I/O is in a network buffer, heap memory, file system buffer, 
> on disk, or split among some combination of two or more of the above?

My working understanding of migrations (vmotions in VMware parlance) is 
that the source host starts replicating memory to the destination host. 
  It keeps track of what has and has not been replicated.  (The guest is 
still running.)  If the guest writes to a page that has been replicated, 
the page considered dirty and needs to be re-replicated.  Eventually the 
source host will be down to only pages that are changing extremely 
quickly.  So the source host pauses the VM, replicates the remaining 
memory pages.  CPU state is also replicated.  Once that is done the 
destination host resumes the guest VM.  The guest has no real idea that 
anything has happened.  The password change that you were in the middle 
of is partially executed on one host, paused, transferred, and resumed 
on the next host.

The over all transfer takes time, but the guest VM is running during the 
vast majority of it.  The guest VM is paused for a very brief period of 
time.  Where very brief is likely on the order of a few hundredths of a 
second, if that.

This type of migration has been standard operating procedure to the 
point that it's an old hat trick.  (Purportedly even the free KVM can do 
this.)

It is so SoP / routine that it is common to run software to monitor load 
on VMware hosts and automatically move VMs around between hosts, 
particularly if you have one demanding more CPU for some reason. 
Automation will move other guests off of that host to give the hog more 
resources.  (Within reasons.)  Or optionally, move the hog to a lesser 
loaded system.

It's so common that VMware doesn't care about vmotions.

> If that's true it sounds impressive.  But if the hypervisors are that 
> good it makes me wonder why Microsoft needed to spend megabucks on 
> making SQL Server and Windows work better under hypervisors (and I 
> believe similar efforts have gone into Linux).

In a word, "Optimization".  They spent time, effort, and money to alter 
how Windows / Linux work to make them even nicer under virtualization. 
You can hot add CPUs and memory to guests if the OS supports it. 
Similarly, you can hot remove CPUs and memory from guests.

So, much like you can move VMs around to balance load, it's also 
possible to move CPU and memory between guests to best "sweat the 
assets" as is commonly said.

I believe there was also effort to make Windows (and likely Linux) more 
clearly expose if a memory page was dirty or not.  The idea being that 
multiple VMs running the same version of the OS, kernel, libraries, 
etc., can have their memory pages deduplicated.  Thus further saving 
memory and making it easier for a hypervisor to know the current state 
of things without needing to understand the nuance of each OSs kernel.

These are (some of) the optimizations that have gone into Windows and 
Linux to make them more friendly to virtualization.  The changes weren't 
done because they /needed/ to be done to make the OS compatible.  They 
were done /opportunistically/ to allow better use of the hardware.



-- 
Grant. . . .
unix || die