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.