How does RAM work in a Virtual Machine?

Question

I have set a Linux Virtual Machine with VBox and the host operating system is Windows. I would like to understand how RAM operates on the Virtual machine.

• Does the host allocate the guest used RAM as a single service?
• or, is the RAM directly allocated by the Guest?

In short, does the host looks the guest as a single application, or the guest system directly assigns its needs to the hardware? I have not studied computer science or something, so I perceive the problem as follow:

• If I do a single calculation in the guest system and the host system perceives the guest as a single service, then the calculation will be one of the many services the guest produces at that time and my calculation will have a delay.
• If the guest directly connects with RAM, then the other services have already allocated in the RAM and they fluctuate and the new will be assigned faster.

Solution

First: The allocation of RAM is always under the final control of the host operating system.

Beyond that, it depends.

With a simple hypervisor you just tell the hypervisor how much RAM each VM gets, That amount is deducted from the available RAM on your host system when the VM starts and is "in use" by the hypervisor as long as the VM is running. The OS running in the VM works as it always does to allocate RAM to processes and to OS uses. The old Microsoft "Virtual PC", which was widely used for running "XP Mode" within Windows 7, works that way. VirtualBox does also. In both, if you configure a VM for 1 GB RAM and start it, your host suddenly has 1 GB less RAM "available". It's usually not very efficient in its use of RAM, but it's simple to implement.

With a more complex hypervisor, the amount you allocate to the VM is simply an upper limit. The guest OS sees that much RAM as "total" but behind the scenes some or even most of what the guest thinks is RAM could be virtual as far as the host is concerned. This is particularly true of what Windows calls "Free" or "Zeroed" RAM in the guest - since it has no content of interest, there is no need to store it anywhere. But even RAM that the guest sees as "in use" could be virtual in the host, with contents in a pagefile or a mapped file.

The guest OS continues to handle RAM as it always does, but if the guest OS refers to some of that not-yet-really-there RAM, the hypervisor can allocate more actual RAM to the guest. (In other words, a memory reference that seems to work without a page fault in the guest might incur a page fault in the host.) Within the total available RAM and the configured limits, the hypervisor adjusts the amount of RAM that's "in" the guest OS to try to keep its page fault rate in the host low.

This is generally called "thin provisioning". It's more complex to implement in the hypervisor but results in more efficient use of the host's RAM.

Comments

[Ramhound]

RAM is allocated to the hypervisor program. RAM cannot allocate itself that makes absolutely no sense. How hypervisors work depends on the type they are and which hypervisor your talking about. In this case a box has documented how they work, and the type of hypervisor they are, is also documented

[phuclv]

there's another technique called memory ballooning supported by both virtualbox and vmware for some guest OSes, which also allows the guest to change the amount of memory, but it's not thin provisioning

[Jamie Hanrahan]

As I've seen it, "ballooning" is more a mechanism that is part of thin provisioning. It allows the HV to easily take RAM away from the guest, or to expand the amount of RAM alloc'd to the guest. "Ballooning" refers to the method used: allocating and referencing a whole bunch of virtual memory, which results in private allocation of RAM - after that the HV can "move" that RAM to the other side. If you're not doing thin provisioning, ie if all of the RAM that's allowed for the guest is actually allocated to the guest when the guest starts, then "ballooning" would be completely pointless.