[Info-vax] VMware

[Dave Froble]

On 12/10/2019 9:35 PM, Grant Taylor wrote:
> 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 all sounds really great.  As I may have mentioned, I've not been 
involved with VMs in the past.  In some ways, but not identical, sounds 
a bit like Galaxy.

Doesn't sound like something that would support real-time, but, that 
doesn't seem to be the market.

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

Yes, very impressive.

Except when I tried to test VMware, it told me my network device was not 
supported.  That wasn't so 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.
>
>
>


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486