|
|
| |
Sep
25
Written by:
Shawn Bass
Thursday, September 25, 2008 4:21:04 PM
Helge Klein from sepago put up a blog entry today discussing the memory overcommit feature of VMware's flagship ESX product and how it has a very favorable impact in the VDI space since you're running lots of copies of MS Windows with the same (or similar) applications on them, etc. (this is likely the result of large amounts of transparent page sharing) Helge also mentioned that Microsoft and Citrix both do not have this feature at this time and are downplaying the significance of it. Helge believes it's this way because Microsoft simply doesn't have this feature now. While I tend to agree that there probably is some level of wordplay to de-emphasize the competitors product that has a feature that your product doesn't have, but I also wonder if there isn't another reason why Microsoft wasn't so quick to implement this feature. Keep in mind that both Vista and Server 2008 have implemented Address Space Layout Randomization (or ASLR) as a tactic to reduce the likeihood that OS exploits can compromise a host system. I have not seen anyone comment on whether or not transparent page sharing works with ASLR or not. I would assume that even if it did work, it probably wouldn't be as effective as it would otherwise normally be. Assuming that's the case, perhaps Microsoft has pushed off this feature since it's not something that would greatly benefit Vista/2008. Everyone knows that Microsoft always has higher level of focus on their newer operating systems than they do on the legacy stuff. Perhaps because of this (and my theory on ASLR's impact to transparent page sharing) they haven't pushed this higher in their priority list for Hyper-V development. Can anyone out there comment on the effectiveness of transparent page sharing with ASLR? Perhaps since's MS's ASLR implementation is rather limited you wouldn't get quite as penalized as a full blown ASLR implementation. However, without having tested any of this I can only speculate.
Tags:
5 comment(s) so far...
Re: Why doesn't Microsoft have memory overcommit / transparent page sharing?
I've only heard from one person - and they were complaining about the low numbers of sharing they were seeing, so I wouldn't be surprised ASLR is having an impact. ESX is looking at each page of memory, computing a hash of it and searching for matching hashes - it's possible the ASLR shifts are enough to drop the number of similar pages significantly.
By Andrew Storrs on
Thursday, September 25, 2008 5:54:24 PM
|
Re: Why doesn't Microsoft have memory overcommit / transparent page sharing?
since ESX hashes pages of 4kb in size and ASLR uses randomization of 64kb blocks, the transparent pagesharing still works perfectly. the blocks will be present at diffent physical addresses but the offset will still be the same. and also, one of the biggest effects of transparent page sharing can be seen in empty pages (memory blocks that windows continously empties out with zeros). they will be zero, no matter what their offset is so they'll share just the same.
also, the effect of pagesharing is bigger than microsoft and citrix will have us believe. in 90-95% of all cases, memory is the first bottleneck a physical host will run into when it's getting up to speed. so having memory shared simply allows for more virtual machines. and ofcourse memory is cheap nowadays but who wants to buy more memory when it's mostly just idle memory anyway. kinda defeats the whole purpose of consolidation and gives me the same creepy feeling as when you buy 1 cpu core per virtual machine...
By brugh on
Friday, September 26, 2008 5:49:49 AM
|
Re: Why doesn't Microsoft have memory overcommit / transparent page sharing?
Good point, Shawn, bringing ASLR into the discussion.
With ASLR, the Windows DLL loader can relocate a DLL to one of 256 positions. That happens for DLLs that are marked for "ASLR safe" in the PE image. During a relocation certain addresses have to be replaced in the code since the DLL is not being loaded at its designated base address. Simply put, writing to code pages in memory breaks page sharing.
Now the interesting question is: which percentage of a DLL's pages is being changed during relocation?
By Helge Klein on
Friday, September 26, 2008 5:56:52 AM
|
Re: Why doesn't Microsoft have memory overcommit / transparent page sharing?
VMware is looking in to ASLR as wel as NX support for there VMsafe solutions. Better protection for the VMkernel, VM's and Applications should be the result.
By PeterB on
Friday, September 26, 2008 7:58:58 AM
|
Re: Why doesn't Microsoft have memory overcommit / transparent page sharing?
Thanks everyone for your comments. It seems like there's still a big question of whether or not memory overcommit is limited by ASLR or not. If I can get some time to do some digging I'll continue to look into this. If anyone else comes across info regarding this, please pass it along.
@PeterB - I am aware that VMware is pursuing ASLR which is a good thing to ensure kernel security. However, that doesn't really have anything to do with guest memory overcommit. Regardless, it's a good move for VMware.
By Shawn Bass on
Friday, September 26, 2008 8:17:10 AM
|
|
|
|
|
|