Hyper-V Program Manager
Jeff has discussed this at some length over on the virtualization team blog, but as a general rule of thumb we believe that it is much better to have paging occur inside the guest operating system rather than at the virtualization layer (if paging is needed).
The simple reason for this is that the guest operating system has far better understanding of which are the best sections of memory to page out – where as all the virtualization layer can do is to guess at what should be paged out.
In my recent demonstrations of dynamic memory I came upon another interesting angle to consider. Here is a screenshot of task manager from a virtual machine that is running at –23% memory availability (i.e. it does not have enough memory available and is paging in the guest):
What is fascinating about this screenshot is that even though this virtual machine is significantly short of memory, the guest operating system is still keeping 112mb memory available / as file cache. The reason for this is that the copy of Windows inside the virtual machine knows that even though it is short of memory – it can provide the best experience for the user of the virtual machine by not using all the memory that it has and by keeping a little bit free to serve as a cache / be there for new applications.
It is exactly this sort of logic that gets lost when paging is done at the virtualization layer instead of inside the guest operating system.
Speaking of demonstrations - I was at your TechEd presentation (in New Zealand) on Monday. I was very impressed, both with the technology itself and the quality of the presentation.
Out of curiosity; has a hybrid approach been tried. Instead of any file access going to the paging file in the VM's VHD -- it gets re-routed to the Hyper-V and the VM Memory Manager decides how it wants to "page" it for the guest. It could page it to unused ram, or to its own paging file. Seems to me that would be the best of both worlds. The VM Manager knows exactly how much memory is physically available; and it probably has a faster disk read/write access by not going to a vhd. And you could configure certain machines to have preference to Memory VM rather than to Disk VM. And if that Memory is needed then HV could page it to file like normal anyways.
@Nathaniel: I'm not Ben and I don't work for Microsoft, but a lot of that isn't necessary with dynamic memory. With regards to the concept of "paging to host memory", if you configure your dynamic memory settings for each VM to have 1GB of startup memory but allow the maximum to go up to the host's total memory (or some other really large number, like 64GB) then that VM can be allocated additional RAM from unused host memory on the fly and avoid paging altogether. If there isn't free memory available then the host can take memory from other VMs and allocate it to the VM in need, assuming that you have set the "Memory Priority" accordingly and that the VM in need has a higher priority.
Regarding paging to a VHD, Microsoft has really tuned the storage stack around VHDs (especially since adding native support for VHDs into Server 2008 R2 and Windows 7). The numbers that I have seen show near native performance (around 5%) versus native disk. On top of that, the way that your storage subsystem is configured can also have a significant impact on how your VHD files perform. For example, if your Hyper-V R2 hosts boot from a local mirror/RAID1 set but all of your VMs are are stored on a high performance SAN (a very common scenario) then paging in the VHD files will still likely be much faster than paging to the host's local disks.
Architecturally speaking I'm not sure how much effort would be involved in breaking that parent/child partition barrier for the purpose of memory paging but there would certainly be security implications of doing so. Given that the benefit, if any, would likely be marginal when compared to the technologies that already exist it would seem like an unlikely path to take.
So at a simplistic level are you saying that we should disable or reduce the host's pagefile to say 200mb (enough for a dumpfile) to enforce the fact that swapping only occurs within the guests and not at the hypervisor level?