Leo’s Ramblings Rotating Header Image

A comparison of important features between Citrix XenServer 5, Microsoft Hyper-V 1.0 and ESXi 3.5u3

I think I’ve got about a dozen emails asking for a simple comparison table, and frankly I think the value of such things are nil because they cannot possibly cover everything.

But, just to get it out there, here’s a table that I quickly threw together, based on the excellent work in this blog

So here’s the table, let me know if I got something wrong:

For my money, I think VMware offers the best features in a production environment but I think it’d be mad to go past XenServer 5.0 in a dev/test or small-office situation – it works, it’s cheap and with technologies like Marathon’s FT-protection product everRun, it’s got VMware beat.

Hyper-V, at present is a dead horse – a market place-holder that Microsoft can only ever consider as a foot in the door. It’s not even the equal of the ancient ESX 2.5 series of hypervisors.

21 Comments on “A comparison of important features between Citrix XenServer 5, Microsoft Hyper-V 1.0 and ESXi 3.5u3”

  1. #1 Secure Citrix Systems » Blog Archive » A comparison of important features between Citrix XenServer 5 …
    on Nov 12th, 2008 at 9:23 am

    [...] Software news by unknown [...]

  2. #2 keith
    on Nov 12th, 2008 at 9:26 am

    very nice chart for comparison.

    Some Hyper-V corrections:
    Offhost VM Backup/Snapshot capability – Hyper-V VSS Writer allows for live backups of VM’s if using a backup product that leverages VSS
    VLAN support – 3rd party NIC drivers provide this support (Intel/Broadcom, etc)
    Resource Allocation/Control – can control cpu, etc with reserves and weights

  3. #3 Leo
    on Nov 12th, 2008 at 9:40 am

    Thanks Keith.

    Updated!

  4. #4 Kirill
    on Nov 12th, 2008 at 10:02 am

    Are you sure about 16Gb XenServer?

  5. #5 Leo
    on Nov 12th, 2008 at 10:05 am

    Hi Kirill,

    According to the System Requirements, yes:

    http://docs.xensource.com/XenServer/5.0.0/1.0/en_gb/installation.html#sys_requirements

    Locally attached storage (PATA, SATA, SCSI) with 16 GB of disk space minimum, 60 GB of disk space recommended

    General disk space requirements for VMs:

    * Product installation creates two 4GB partitions for the XenServer host control domain; remaining space is available for VMs
    * VMs based on the Debian templates are allocated a 4GB root device, and a 512MB swap device
    * Linux VMs are allocated a root device of 8 GB
    * Windows Vista VMs are allocated a root device of 16 GB, and other Windows VMs default to 8 GB.

  6. #6 keith
    on Nov 12th, 2008 at 12:20 pm

    DRS like functions are provided by integrating 2 System Center family products together (System Center VMM 2008 and Operations Manager 2007) integration which provides PRO (Performance Resource Optimization); this provides intelligent placement, VM migration,etc.
    http://www.microsoft.com/systemcenter/virtualmachinemanager/en/us/top-ten-benefits.aspx
    http://www.microsoft.com/systemcenter/virtualmachinemanager/en/us/pro-partners.aspx

  7. #7 Leo
    on Nov 12th, 2008 at 4:16 pm

    Hi Keith,

    I agree with that, however it’s at best server monitoring. It does not do DRS as DRS migrates machines while live. It does do placement though.

    I’ve amended the feature table

  8. #8 Ralph
    on Nov 12th, 2008 at 11:15 pm

    XenServer 5 now carries 1 year of log data, up from the 15 minutes of 4.1.

    Granularity of data lessens the older it gets.

    Snapshots are available on NFS, NetApp and (I think) Equalogic storage – hot backups for Windows use VSS to quiesce the filesystem.

  9. #9 keith
    on Nov 13th, 2008 at 6:50 am

    agreed; today those migrations would be quick-migration (suspend/move/resume); but still a feature that comes via PRO integration of VMM/OpsMgr and having agents on Hyper-V hosts and inside guests that gives us a clearer performance picture than just load balancing via algorithm as DRS does. Only the tip of the iceberg re: PRO; can do much more than placement and migration

  10. #10 Leo
    on Nov 13th, 2008 at 7:03 am

    Ralph: Thanks, I’m changing that as we speak – however I’m leaving the hot backup stuff out, simply because it’s SAN-dependant.

    I’m looking at more integrated – single-VM only backups that are SAN-agnostic. Kind of like VCb or Microsoft’s VSS Writer that don’t need to know about the SAN below them to back up VMs.

  11. #11 Tamas
    on Nov 15th, 2008 at 7:29 am

    At my space, I’m doing some comparison as well. ;-) Check under “IT 2.0″ category. Some corrections:

    VLAN is supported natively in Hyper-V
    NPIV is supported by Hyper-V
    With MPIO there is Storage I/O load balancing in Hyper-V (more feature rich than ESX/ESXi)
    ESXi supports RHEL, SUSE, and UBUNTU as Linux. Other Linux distributions are supported by Vmware Server.

    Some features requires Virtual Center for ESXi. For Some features Hyper-V needs SCOM/SCVMM. I would take a note or a sign for that feautures.

    PRO is definitely a resource redistribution function – but yes, it could causes downtime. However, think about RDP, Exchange cached mode or other clients which tolerates network outage. It can be used in those sceanrios.

    ESXi has not “optimized” drivers – if you think about performance. Drivers are “compiled into” ESXi. In such a context, yes, drivers are optimized.

    Cheers,

    Tamás

    Ps.: Sorry, my knowledge about Xen is limited. :-(

  12. #12 Leo
    on Nov 15th, 2008 at 9:04 am

    Hi Tamas,

    I’ve updated – thank you.

  13. #13 Gabrie
    on Nov 17th, 2008 at 2:28 am

    Hi
    Regarding the last point (Hardware comptibility), it is true that ESX has a strict HCL, but when you look at the large number of supported systems, you will surely find a system that is supported and suited for your needs.

  14. #14 Leo
    on Nov 17th, 2008 at 2:41 pm

    Hi Gabrie,

    Yes, it’s true that you can find a system but the fact of the matter is that I’m running Xen and Hyper-V on custom-built white boxes on the cheapest components I could find.

    You can’t do that with VMware. You can only match what VMware ahs drivers for.

    Cheers,
    Leo

  15. #15 A comparison of important features between Citrix XenServer 5, Microsoft Hyper-V 1.0 and ESXi 3.5u3 | Richard Parmiter
    on Nov 25th, 2008 at 7:31 pm

    [...] Originally posted here [...]

  16. #16 Comparison: Citrix XenServer 5, Microsoft Hyper-V 1.0 and ESXi 3.5 « Hotware: Dirk’s Software Blog
    on Dec 9th, 2008 at 4:08 am

    [...] A comparison of important features between Citrix XenServer 5, Microsoft Hyper-V 1.0 and ESXi 3.5 [...]

  17. #17 Andrew
    on Jan 26th, 2009 at 5:48 pm

    I think the size on disk is a bit misleading – While it’s true that XenServer requires 16GB to install, that’s not the size of the hypervisor – which is what you refer to with ESXi.
    If you want to compare the hypervisor size, then 32 MB for ESXi, 500kb XenServer (I think Hyper-v is 1.5 mb but not sure).
    Please amend your table with the required disk space to install each product or the hypervisor size, but at least make it consistent!
    I’d drop the security row as well – VMSafe is currently vapourware and has been for about 4 years. maybe it might get released with VI4, but not yet…
    I could go on and on (there is no host OS for XenServer or Hyper-v – both are bare metal hypervisors which utilise a control domain – even ESXi has a control domain which is Busybox Linux).

  18. #18 Leo
    on Jan 27th, 2009 at 11:31 am

    Hi Andrew,

    You’re right on the size – ESXi installs in 560MB – my mistake. I’ve also dropped VMsafe – when I made the table originally I had it on good authority that the release was not far away.

    There is a host OS for XenServer and Hyper-V – neither can run without a control domain to buffer I/O and network info.

    While the same is true with ESXi, it’s not a control domain per se. This is reasonably easy to see – Xen utilises Linux drivers for all devices, as does Server Core. ESX/ESXi have Linux-derived drivers but they are not loaded in the Linux instance. Rather they are loaded into the vmkernel.

    Cheers,
    Leo

  19. #19 Ron kuper
    on Mar 9th, 2009 at 9:00 pm

    Control Domain is not necessarily a disadvantage as you imply in the table (”Optimized Drivers vs. Generic Drivers”).

    “Optimized” is a bit misleading. Can you say linux/windows drivers as less “Optimized” than VMware’s?

    Drivers in the hypervisior/Drivers in a “Control Domain” are different hypervisor architectures (such as full emulation vs. paravirtualization), each with its own pros and cons.
    Benchmarks are available and favor one platform to another usually depending on the type of load tested. (And, unfortunately, the affiliation of the person who tested it).
    Every organization which considers virtualization and cares
    about performance should perform its own scalability and performance testing.

    Anyway “Optimized” have no real value as useful information.
    (And much less so “Generic”…)

  20. #20 Leo
    on Mar 10th, 2009 at 6:58 pm

    Depends. See, with Hyper-V, the nature of the OS means you can use any NIC and any HBA, whether or not it has been tested in WHQL labs.

    This means that drivers are naturally less hardened and less controlled than the VMware ones where VMware works with the IHVs to develop drivers specifically for ESX/ESXi.

  21. #21 Ron kuper
    on Mar 11th, 2009 at 12:06 am

    Flexibility is not a bad thing.

    That something is technically possible (e.g. using non WHQL Drivers) is not to say that it is good or recommended.

    I’m not ruling out VMWare’s drivers from being optimized (are they really making their own drivers for all of the qualified hardware?), but if a vendor can and allow you to use uncertified/3rd party drivers does not necessarily mean that the certified drivers are not doing a great job.

    I don’t think that we can currently say which approach is better (Control domain vs. drivers in the hypervisor). Both have pros and cons. For instance with the driver domain you can have several drivers domain and have each guest connected through a different domain so that a driver fault will not bring down the host.

    Just don’t degrade the discussion to “Optimized” vs. “Generic”. Doing so means ignoring important points.

Leave a Comment