Wednesday, March 4, 2009

[THIN] [Renamed] Hypervisor comparison

Like you we're trying to make a decision on which way to jump. Have you considered/had the ability to test in quantities sufficient to test the effect of VMware RAM page sharing?

There is an interesting response to a MS/Vmware blogging war from http://blogs.vmware.com/virtualreality/2008/03/cheap-hyperviso.html (reproduced below).
************************************************
Posted by: AP | March 14, 2008 at 05:48 PM

To address memory overcommit (no pun intended), I would like to offer up a quick case study where memory overcommit works in my company of 160,000 employees. A few weeks ago I begain posting preliminary analysis of running production Citrix Presentation Servers inside VMs on ESX 3.x (see http://communities.vmware.com/message/863920). My preliminary findings show that the production Citrix VMs are taking advantage of Content Based Page Sharing (for a detailed explanation of VMware's Content Based Page Sharing, see Carl Waldspurger's whitepaper on Memory Resource Management in VMware ESX Server at http://www.waldspurger.org/carl/papers/esx-mem-osdi02.pdf). One virtualized Citrix server is handling 50-85 sessions and it's not full yet. Each of the sessions is running one of three published applications that all share the same base PowerBuilder code and .DLLs (about an 80MB memory footprint for each session). Because each of the 50-85 sessions shares the same code, the VMware's Content Based Page Sharing consolidates many of the identical pages into single read only reference points and discards the redundant copies. The net result is significant ESX host memory savings. As an example, what I'm seeing inside the Citrix VM is nearly 4GB of RAM being used, but from the ESX host perspective, 1GB or less physical RAM is being utilized, leaving the additional 3GB of physical RAM for another VM in the cluster to use. Now multiply this memory savings by the number of virtualized Citrix servers and the memory savings adds up quickly.

In the blog banter, a point is made by the opposition that it's going to be rare for a number of VMs on the same host to all be identical such that there would be a significant savings in memory page sharing. My example is proof that you don't even need multipe VMs to take advantage of VMware's page sharing and memory overcommit. The fact is that VMware's Content Based Page Sharing works both inter-VM (across VMs) and intra-VM (within a single VM). I verified this with Carl Waldspurger himself a few weeks ago. Summary: Citrix VMs running silo'd or partitioned application sets take advantage of intra-VM Content Based Page Sharing.

On the inter-VM Content Based Page Sharing front, an assumption is made by the opposition that rarely will VMs share the same code to amount to any sort of memory savings. I don't have hard numbers yet but I will say that in our VDI deployment that we are rolling out, all Windows XP images are rolled out from the same template which contains all of the tools each VDI user needs to do business. While there is no guarantee each VDI user will concurrently be running the same applications within their VDI, it's a fact that at a minimum they will each be running the same base operating system (Windows XP), Microsoft Outlook plus all of the MS Office code that loads in the background and at startup. Most will probably have at least 1 IE browser open as well, although the IE footprint is fairly minimal in the grand scheme of things. Depending on the number of virtual desktops we deploy on each host, I think we'll see generous memory savings. This is not to say we will intentionally overcommit memory. Ballooning and VMKernel swap allows memory overcommit but I'm not that desperate to take the performance hit that comes with it, although I'm not sure whether or not our VDI users would be able to tell the difference or not.

Jas


*************************************************
-----Original Message-----
From: thin-bounce@freelists.org [mailto:thin-bounce@freelists.org] On Behalf Of Matt Kosht
Sent: 04 March 2009 13:36
To: thin@freelists.org
Subject: [THIN] Re: XenServer 5.0 Tools/Adobe Acrobat 8.x on a Terminal Server

It's been quite good other than this issue. Right now I would rank the
hypervisors for this task (Citrix/TS) 1. XenServer 2. Hyper-V 3. ESXi
(dedicated) 4. ESX (shared hardware with other VM's of other types).
They are all capable of the task. ESX requires some extra research and
tweaks to compete with the others though. We use VMWare a lot for
other VM's so I wouldn't have predicted this outcome. XenServer
performs well, but it's a bit rough around the edges with some
annoying bugs.
Still need to get some hard data on performance vs. the physical, but
I can tell you not 1 user has said whenever I am on VM server X (they
know which server they attach to) it stinks, but when I get on
physical server Y it works much better. I know there is a holy war
out there to virtualize Citrix or not, but I would say it's worth it
to at least try it. Same arguments about having a bunch of
underutilized physical servers in the non-TS world apply in Citrix now
that hardware is so far past the capabilities of a 32 bit Windows OS.
I also want to test a single 64 bit Terminal Server vs. multiple 32
bit VM's on same hardware, but my gut tells me it won't scale as well
because most of our apps will run 32 bit anyway.
-Matt

On Wed, Mar 4, 2009 at 3:07 AM, Nick Smith <nick@officeanyplace.com> wrote:
> Cant help with that, but what has the performance been like on the different platforms?
>
> Sent from my Windows Mobile(r) phone.
> - Show quoted text -
> ----- Original Message -----
> From: Matt Kosht <matt.kosht@gmail.com>
> Sent: 04 March 2009 03:42
> To: thin@freelists.org <thin@freelists.org>
> Subject: [THIN] XenServer 5.0 Tools/Adobe Acrobat 8.x on a Terminal Server
>
>
> OK bear with me, this one has drove me nuts for about a month. Acrobat
> 8 runs fine on physical W2K3/PS4.0 term servers, Hyper-V VM's and
> ESXi/ESX VM's with the same specs as the physical. I have been running
> them all head to head to see which one works best for our environment.
> On XenServer hosted VM's Acrobat 8 would lock up just opening the
> program. I tried lots of things to fix it (reinstalling it, repairing
> it, etc) I finally broke down and built a brand new clean VM on
> XenServer 5.0 so I could figure what on earth was causing this. I did
> a straight Windows 2003R2 32 bit Standard SP2 install with the
> XenServer tools, enabled terminal services, installed Office 2003 (so
> I could see if the integrations with Acrobat worked). I turned off
> DEP just to rule it out as well. I installed Acrobat 8 Standard and
> it locked up as it did on my production image. The version was 8.0 at
> this point i then tested each update incrementally with the same
> result up to 8.1.3. The only thing I could possibly think was
> different with so little installed on the VM was the XenServer tools.
> Bingo uninstalling them fixed Adobe! Reinstalling them breaks Adobe.
> Has anyone else encountered this? Any thoughts to how to fix it would
> be mighty appreciated.
> -Matt
> ************************************************
> For Archives, RSS, to Unsubscribe, Subscribe or
> set Digest or Vacation mode use the below link:
> http://www.freelists.org/list/thin
> Follow ThinList on Twitter
> http://twitter.com/thinlist
> Thin List discussion is now available in blog format at:
> http://thinmaillist.blogspot.com
> Thinlist MOBILE Feed
> http://thinlist.net/mobile
> ************************************************
>
> SUBJECT TO CONTRACT
> ************************************************
> For Archives, RSS, to Unsubscribe, Subscribe or
> set Digest or Vacation mode use the below link:
> http://www.freelists.org/list/thin
> Follow ThinList on Twitter
> http://twitter.com/thinlist
> Thin List discussion is now available in blog format at:
> http://thinmaillist.blogspot.com
> Thinlist MOBILE Feed
> http://thinlist.net/mobile
> ************************************************
>
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://www.freelists.org/list/thin
Follow ThinList on Twitter
http://twitter.com/thinlist
Thin List discussion is now available in blog format at:
http://thinmaillist.blogspot.com
Thinlist MOBILE Feed
http://thinlist.net/mobile
************************************************

SUBJECT TO CONTRACT
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://www.freelists.org/list/thin
Follow ThinList on Twitter
http://twitter.com/thinlist
Thin List discussion is now available in blog format at:
http://thinmaillist.blogspot.com
Thinlist MOBILE Feed
http://thinlist.net/mobile
************************************************

No comments: