Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1

White Paper I Citrix XenServer
www.citrix.com
Comparison of Citrix XenServer 6.2
And VMware vSphere 5.1

Comparison of XenServer 6.2 and vSphere 5.1
Table of contents
Introduction...............................................................................................1
Overview and history of server virtualization.........................................1
Why workloads matter..............................................................................3
General-purpose server virtualization .........................................................3
Memory management ..................................................................................................... 3
Storage management...................................................................................................... 4
Infrastructure management ............................................................................................. 6
Desktop virtualization..................................................................................6
Template management ................................................................................................... 6
Storage management...................................................................................................... 7
Graphics optimization...................................................................................................... 7
VM density ...................................................................................................................... 7
Cloud services ............................................................................................8
Advanced network management..................................................................................... 8
VM density ...................................................................................................................... 9
Pricing scenarios....................................................................................10
Traditional server virtualization .................................................................10
Desktop virtualization................................................................................10
Cloud services ..........................................................................................11
Conclusion – The Hypervisor is now a Commodity.............................12

Introduction
Over the past several years, server virtualization has become mainstream with analyst estimates that
more than fifty percent of all servers are now virtualized. Customers have choice in which hypervisor they
wish to choose for their virtualization projects, and there is an increasing trend towards multiple
hypervisors in datacenters. In this paper, we’ll compare key functional areas between VMware vSphere
5.1 and Citrix XenServer 6.2, and highlight how each solution compares for the critical workloads being
deployed in datacenters today.
Overview and history of server virtualization
VMware and Citrix are pioneers in the world of x86 server virtualization that currently market their
hypervisor solutions as VMware® vSphere® and Citrix® XenServer®, respectively. vSphere was
originally developed under the brand name ESX, with its first release in 1998. The primary objective of
ESX was to more efficiently utilize the compute capacity of x86 servers, which were typically running at 10
to 20 percent utilization. Consolidation of servers onto a single virtualization host permitted greater
utilization of the host server, but also provided significant savings in energy for power and cooling.
As a bare-metal hypervisor, ESX is installed on the host server and guest virtual machines (VMs) are
created for each server being consolidated on that host, with core ESX management services provided
via a service console VM. Given limitations in the x86 instruction set, virtualizing an operating system
required the hypervisor to trap specific instructions and then modify the operating system code to emulate
the correct instruction behavior. While effective, the use of emulation also imposed a significant
performance penalty for the guest VMs.
As server consolidation proved effective, ESX was enhanced with several key features including
clustering and live VM migration. These features enabled more efficient management of the virtual
infrastructure by reducing the downtime associated with key operations such as host maintenance. The
server consolidation movement also presented VMware with a series of new, often niche, requirements
for classes of server workloads to be consolidated, such as serial port management. It also introduced
additional challenges based on increased usage of server consolidation, such as managing the memory
utilized by the core operating system of each VM.
This evolutionary heritage has defined the modern
vSphere hypervisor, and its legacy can be seen in
the vSphere feature set as well as the operating
systems supported.
XenServer is based on the Open Source Xen®
Project hypervisor project initiated at the University
of Cambridge in the United Kingdom, whose first
public release was in 2003, and which is now a
collaborative project of the Linux Foundation. In a
Xen Project-based deployment, the bare-metal Xen Project hypervisor is installed on the hypervisor host
and all VMs are called domains, with core services in the privileged control domain, dom0. Guest VMs
run in unprivileged domains and typically access hardware via dom0.

One of the key advancements of the Xen Project hypervisor is paravirtualization, the notion that operating
systems become aware they have been virtualized. Without awareness of their virtualization status,
operating systems are free to execute CPU instructions which assume direct control of the CPU and thus
create performance bottlenecks. Through virtualization awareness, operating system performance
bottlenecks can be removed and allow guests VMs to operate more efficiently. While Open Source
operating systems can be fully modified to achieve awareness, closed source operating systems such as
Microsoft® Windows® can also benefit from paravirtualization through the use of paravirtual drivers on
key devices. When combined with advancements in processor technologies such as Intel® VT and AMD-
V, XenServer avoids the performance bottlenecks and challenges associated with the emulation model
used in ESX.
In response to the work on paravirtualization in Xen and the advancements underlying chip technology,
VMware adopted paravirtualized device drivers and began to drop its use of emulation. The hypervisor
resulting from this work, named ESXi, proved so serviceable that with vSphere 5.0, VMware retired the
ESX architecture. Today there are few performance differences between hypervisors, and the hypervisor
has become more of a commodity leading the comparison between vendors to be more functional rather
than pure performance.

Why workloads matter
At the time vSphere was designed, the core requirement for a hypervisor was server consolidation. VM
densities associated with that scenario were at most tens per server, and the workloads themselves were
largely utilitarian. You can still see this low density design mindset when looking at the “monster VM”
capabilities of vSphere, which have increased the capabilities to support very large VM sizes with
vSphere 5.1, but with no corresponding increase in VM density. While this model does hint at an
understanding that workloads matter, there is minimal evidence that vSphere is designed with the
majority of workload types in mind; rather it seems to be designed to perform best for general-purpose
workloads while avoiding any optimization for specific workload scenarios.
General-purpose server virtualization
In a general-purpose server virtualization scenario, the key features of the virtualization infrastructure are
memory, storage and infrastructure management.
Memory management
Memory management functionality, also commonly referred to as memory over-commitment, was
implemented at a time when the ability to over-commit the CPU on a virtualization host resulted in RAM
becoming the defining element in the cost of the host. To resolve this, it was observed that the operating
system memory usage was often a large of the memory allocated to a system, and that within a server
consolidation scenario the same operating system was usually present in multiple VMs. Coupled with the
understanding that servers were often provisioned with surplus memory due either to an expectation that
applications would use available RAM or that servers were only available with discrete RAM values, it
became accepted that overcommiting the memory on a virtualization host led to effective management of
the overlap and utilization of memory across VMs.
Within a vSphere environment, there are three options available for memory management; ballooning,
page sharing and swap with compression. Ballooning is used for situations where the VM is configured
with more memory than it is actually using. Page sharing is used to address the commonality of
operating system memory pages. Swap is only used when the combined VM usage of memory exceeds
the available RAM on the host. To minimize
inherent performance problems associated with
swapping memory, swapped memory is
compressed to minimize the IO associated with
recovering it.
Unfortunately, as is often the case with
evolutionary products, the original assumptions are
no longer as compelling. Modern operating
systems, in an attempt to prevent malicious
tampering, now randomize and sign their memory
pages. Additionally, in an effort to increase
performance, they now implement large memory page layouts and leverage unallocated memory for
system caches. Randomization of memory pages and the use of large memory pages can neutralize the
benefit of page sharing, while the use of unallocated memory for system caches impacts the degree to

which memory ballooning should be used. Couple these items with cost-effective servers with 128 to 256
GB of RAM and memory over-commitment strategies become less relevant.
In recognition of these trends, XenServer uses a balloon memory management model. Administrators
select a maximum and minimum value for the memory balloon driver. When a VM starts up on a host
with ample memory, the amount of free memory seen by the VM corresponds to the maximum configured
value. In the event the memory requirements of additional VMs on the host cause the memory on the
host to become oversubscribed, the XenServer host requests that VMs with available free memory
release it to the host. This allows XenServer to provide meaningful memory management when host
RAM is the limiting factor for VM density, while not imposing performance or security penalties on the use
of memory over-commit strategies.
Storage management
Storage is one of the most crucial factors in determining the overall cost of a virtualization solution, and
there are many options that can affect this cost. To allow VM migration between virtualization hosts, a
shared storage model is often used. In a shared storage model, a SAN or NAS device is connected to
the virtual infrastructure and one or more volumes or LUNs are presented for use. The connections are
usually redundant, regardless of whether they are made using iSCSI or NFS or via an HBA. Since server
consolidation often involves mission-critical data, multiple storage options are often concurrently in use,
and a given LUN may map to a specific VM disk.
vSphere addresses this complexity with a proprietary file system, VMFS, which is leveraged over the
underlying storage solution. The disk images are then stored on VMFS datastores in a proprietary file
format, vmdk. The vmdk specification is updated with each vSphere release; leading to compatibility and
portability issues during upgrades. vSphere also supports direct integration with specific arrays using a
technology called vStorage APIs for Array Integration (VAAI). When combined, these solutions provide a
resilient storage model upon which to build a virtual
infrastructure. However, it is important to note that
VMware regularly updates the vmdk format, raising
portability issues when planning for disaster recovery.
XenServer does not impose a proprietary file system for
shared storage; rather it leverages the Microsoft open
specification for the virtual hard disk (VHD) format to
define the actual VM disk and uses the Linux® logical
volume manager to handle the underlying disk systems.
This adherence to an open standard ensures that
portability issues endemic to proprietary file systems are avoided. In situations where a LUN-per-VDI
model or direct array integration are required, XenServer has StorageLink. StorageLink provides direct
array integration for popular storage solutions from NetApp, Dell and EMC, which provide a high-
performance and resilient storage sub-system upon which a virtual infrastructure can be built. Looking
beyond the basic topic of storage management, general-purpose server virtualization also has
requirements for migration of storage associated with a running VM and for management of storage
between disaster recovery sites.
One of the most important
considerations in migrating storage
over general-purpose networks is
ensuring the security of the data being
transferred

Live storage migration
VMware pioneered the technology of live storage migration and branded it Storage vMotion to align with
its live virtual machine migration brand, vMotion. This technology allowed administrators to migrate the
underlying storage for a VM without incurring significant downtime, and became popular for array
maintenance and resizing storage. In its original form, Storage vMotion functionality was limited to
migrating the storage within a single vSphere cluster, but with vSphere 5.1 that restriction has been
removed and both storage and VM state can be migrated between vSphere clusters.
Unlike vSphere, with its heritage of cluster
management, storage migration for XenServer was
designed with cloud scale in mind. This feature,
Storage XenMotion was not designed with an
assumed cluster boundary to limit it. One
advantage of designing without the confines of a
clustering solution was that the realities of
datacenter networks versus storage networks were
designed in from the start, and one of the most
important considerations in migrating storage over
general purpose networks is ensuring the security of
the data being transferred.
Further, the design criteria included migration across all types of native XenServer storage options,
resulting in a support matrix including everything from local storage through fiber-based storage arrays.
Disaster recovery planning
Disaster recovery planning is one of the most common scenarios associated with modern server
virtualization project. Features inherent to virtualization, such as hardware independence, become even
more important when disconnected datacenters are involved. vSphere includes an optional component
called Site Recovery Manager, which facilitates planning and management of a vSphere environment
involving multiple sites. Site Recovery Manager assumes that the vSphere product version and the
underlying storage in different sites are
compatible. Compatibility is required, as Site
Recovery Manager automates not only the
vSphere environment but also the storage
systems’ replication between sites. By
performing this level of deep integration, Site
Recovery Manager ensures that the vSphere
administrator is in control of disaster recovery
planning.
XenServer also has a disaster recovery
planning module, but unlike its vSphere
counterpart, the Integrated Disaster Recovery feature is, as its name implies, fully integrated with the
XenServer infrastructure. What sets this feature apart from vSphere Site Recovery Manager is the
recognition that disaster recovery planning is a complex proposition typically involving many technologies
and departments within an IT organization. In a XenServer environment, Integrated Disaster Recovery

takes care of all virtualization aspects including VM disks, VM metadata and the network configuration,
while leaving the task of configuring storage replication to the storage system administrators. This
ensures that an organization’s disaster recovery runbook and best practices can be implemented without
any risk of an accidental override by virtualization administrators. It further ensures that during testing of
a disaster recovery plan or recovery from an actual outage, virtualization administrators are working
closely with their storage counterparts.
Infrastructure management
In a vSphere environment, the infrastructure is managed using an external tool called vCenter. vCenter is
installed on a dedicated management server and requires an underlying database server to store its
configuration information. vCenter is a powerful tool providing management and tuning options for
individual vSphere hosts as well as vSphere clusters and groupings of clusters. The health of a vSphere
environment is directly related to that of the vCenter management server. To ensure the overall health of
the vCenter server, VMware sells a number of add-on products designed to overcome the risks
associated with an external management server.
One of the more interesting aspects of vCenter is the evidence of its heritage of single-host management
in many of the configuration options. For example, configuring network options using the vSphere
standard network switch requires administrators to make the configuration change on each host
individually, regardless of the clustering options chosen.
In contrast, a XenServer environment uses a fully replicated configuration database with a master-slave
model, which allows any slave to become a master as required. This model avoids the requirement for
external management tools or a management server, and allows a XenServer resource pool to be fully
configured from any of the nodes in the pool. When a graphical interface is required, XenCenter can be
installed on any Microsoft Windows-based PC. Additionally, the XenServer Web Self Service component
provides delegated VM-level access via a web browser. If direct integration within a larger systems
management suite is desired, XenServer ships with components supporting Microsoft System Center.
Also, other vendors have chosen to integrate using either the XenCenter plugin architecture or the fully
documented XenServer APIs.
Desktop virtualization
Unlike the heterogeneous environment with low VM density typical of traditional server virtualization,
desktop virtualization is characterized by comparatively high VM density, use of a limited number of VM
templates and high IO requirements, particularly during specific times of day. These attributes require
that a hypervisor be optimized for desktop workloads, but the optimizations also include a requirement to
understand how users interact with desktops and what they expect from a computing environment. The
net result is that a virtualization environment designed to handle general-purpose workloads may not
perform optimally in a desktop environment.
Template management
In a desktop virtualization environment, the desktop broker defines a series of VM templates. When a
user requests a new desktop, that desktop is provisioned from the template. One of the provisioning
models available in XenDesktop is a template management system called Provisioning Services (PVS),
which can be used with the Citrix® XenDesktop® desktop broker. PVS was designed to support the

consistent deployment of a golden machine image in both virtual and physical environments. When used
with XenDesktop, the desktop broker creates the VM, and then instructs PVS to stream the golden image
into that newly provisioned VM. User and application data generated while using the streamed image can
be stored either on the PVS server or the local disk on the target computer. In a XenServer environment,
the local disk of the XenServer can be used for this cache, providing a highly scalable solution with
minimal IO impact on the network or any shared storage.
Storage management
XenDesktop also includes a template management system called Machine Creation Services (MCS).
Simpler than PVS, MCS is designed for smaller installations. VMs provisioned using it are assigned one
or more local disks from shared hypervisor storage. Shared storage allows a template to be cloned using
the storage array and then seamlessly provisioned to the hypervisor. While optimizing performance,
machine creation services works with XenServer IntelliCache to offload the IO from the storage array and
minimize any IOP bottlenecks. This approach helps prevent the desktop virtualization project from
becoming blocked by storage array costs associated with provisioning storage for peak IO.
Operating together, machine creation services and IntelliCache recognize that within a desktop
virtualization environment, the number of templates in use is limited. Upon first use of a template,
IntelliCache copies it to local storage on the XenServer host. Subsequent requests for the same template
generate a local clone of the original template. This use of local storage can substantially reduce the
number of IO operations the shared storage array is required to deliver.
Graphics optimization
Typically, a desktop virtualization project comprises different classes of users. Some will require only
basic graphics support and for them, the embedded graphics chip on the server is sufficient to deliver the
desired performance. Other users, such as those in the engineering or medical fields, require
significantly greater graphics performance than embedded graphics chips can deliver. To accept desktop
virtualization, such users must feel comfortable that a virtual desktop can meet their graphical
performance expectations.
XenServer achieves delivers high performance graphics through the use of GPU pass-through
technology. One or more high-performance GPU cards, such as the NVIDIA GRID K2 or AMD FirePro,
are installed in the XenServer host, and then dedicated to the specific users’ VM. Users enjoy secure,
remote access to graphics-intensive applications without sacrificing performance. In contrast, the vGPU
model employed by vSphere attempts to over-commit the GPU and provide an emulated GPU to the VM,
resulting in shared access. Since a GPU is designed with a long command pipeline, and highly parallel
non-interruptible thread execution engines, over-committing access reduces a GPU’s overall efficiency.
VM density
In a virtual desktop project, the number of VMs a host can handle directly impacts return on investment
(ROI). Unfortunately, adding more desktops to the host is not without risks. Host failure, for example, will
cause the loss of all running virtual desktops, and greater VM density increases the impact of those
failures. Careful design allows a balance between ROI and risk with the resultant density being what an
organization can realistically absorb in the event of host failure.

The configuration maximums for vSphere and XenServer seem to indicate that vSphere can handle
significantly more VMs than XenServer. However, closer scrutiny shows that the vSphere maximum
density is in fact a technical limitation which has remained
unchanged for many year and which has minimal bearing on
the reality of any deployment. In fact, despite the releases of
more-capable CPUs from Intel and AMD, the maximum
number of VMs vSphere can run has remained constant.
Further, there appear to be no performance studies showing
deployments even approaching the published maximum.
Citrix, by contrast, has never published a value for the
maximum number of VMs XenServer can handle. Instead the company publishes a supported limit to
provide confidence that, regardless of the server configuration, customers will succeed as long as they
choose a server that could reasonably be expected to run the specified number of VMs. The reason for
this approach is that decisions relating to storage and network choices, as well as operating system
configurations, affect calculation of the maximum number of VMs on a system. With each release, Citrix
has increased the published number of VMs XenServer can comfortably handle. Currently, the supported
limit for XenServer 6.2 is 225 VMs per host.
Cloud services
Cloud and cloud services are among the hottest IT topics today. Regardless of whether the aspiration is
to offer a public cloud for managed services or something a bit more modest, such as an internal private
cloud, cloud is the newest use case for virtualization. What differentiates cloud services from traditional
server virtualization is the combination of high VM density with tenant isolation. This latter is key to
successfully delivering cloud services, for without tenant isolation customers are concerned their private
data is somehow accessible to a competitor and their IT organization will fail a compliance audit.
Advanced network management
At its most basic level, tenant isolation can be achieved by assigning each tenant a dedicated
virtualization host and VLAN. However, even with this model, advanced network management is
required. The ability to control and monitor the network performance of each VM and to mirror traffic and
control its flow to the VM is vital. Simple network management at the physical network is insufficient in
the face of VM agility. For example, defining a network policy on a physical switch port to protect against
rogue VM traffic only works as long as the VM itself does not migrate to a different host. The solution to
advanced network management in a virtual environment is a virtual switch.
vSphere provides three options for virtual networking: standard switch, virtual distributed switch and the
virtual distributed switch with an optional extension from either Cisco or IBM. Since the standard switch is
configured at each host independently of other hosts, it is not appropriate for use in a cloud environment.
This then leaves the virtual distributed switch. In vSphere 5.1 it has been enhanced with some basic
access control capabilities as well as NetFlow and RSPAN for monitoring. Full network flexibility relies on
the Cisco Nexus 1000v or IBM 5000v.
Unlike vSphere, which is late to the virtual networking space and relies on costly third-party add-ons,
XenServer has been shipping advanced networking as an available integrated network stack for several
years. The XenServer distributed virtual switch relies on the Open vSwitch and supports OpenFlow as its
XenServer has been shipping
advanced networking as an available
integrated network stack for several
years

control plane. XenServer supports tenant isolation using ipset, VLAN and cross-host GRE tunnels. The
XenServer distributed virtual switch allows network policies to be defined at the VM level, and these
policies are automatically migrated when a VM is migrated. They can consist of simple NetFlow or
RSPAN definitions and can include both firewall rules and quality of service (QoS) settings. Additionally,
the virtual switch supports the creation of LACP networks and uses portfast to minimize the potential for
IP spoofing between tenants.
VM density
As in desktop virtualization, VM density is a key topic for cloud builders. In cloud environments, risk from
high VM densities comes from the loss of client workloads, not the loss of a group of users. Unlike
desktop virtualization, VMs hosted in a cloud are likely to be diverse and have significant configuration
differences. This heterogeneity presents a further challenge to VM density: customers of cloud operators
expect performance between workloads to be consistent, despite the potential for one client’s workload to
impact the performance of another’s. To solve this, many cloud builders elect not to leverage the over-
commit options within a hypervisor in favor of the predictability of workload performance. If resources are
over-committed, the degree of over-commitment is minimal. In practice, this means the number of VMs a
host can support is more in line with the number of vCPUs that can be scheduled on the host, and VM
densities rarely approach the theoretical maximums for any hypervisor.

Pricing scenarios
The following pricing scenarios are based on a requirement to provide a fully supported virtual
environment featuring:
 Graphical management user interface with no single point of failure
 VM protection against host failures
 VM-level network monitoring
 Cluster-level configuration for all virtualization elements, including storage and networks
 Workload placement services
 Ability to over-commit RAM
 Live VM migration
 Live VM storage migration without pool/cluster limits
Since the cost of virtualization infrastructure is related to the costs of licensing, ongoing software
updates and production support, scenarios assume a three-year investment. XenServer is available as
a single SKU, and the vSphere product is the Enterprise Plus Edition. The chosen hardware will have
dual sockets, but the hardware costs are not included in these scenarios. All prices are USD and
accurate as of July 1, 2013.
Traditional server virtualization
For this pricing scenario, a total of 10 virtualization hosts will be required.
XenServer vSphere
Host license cost 20 Sockets: $21,000 20 Enterprise Plus: $71,900
Host subscription and
support
Three years of maintenance: $6,000 Three years of SnS: $52,400
Management license cost XenCenter is free vCenter: $4,995
High availability for
management server
Not required as XenServer has no
single points of failure
vCenter Heartbeat: $9,995
Management subscription Included Three years of SnS: $10,343
Total $27,000 $149,163
In this pricing scenario, not only does XenServer have a lower cost of acquisition, but its three-year
operating costs, including the cost of acquisition, are less than the three-year subscription costs
associated with the vSphere hosts.
Desktop virtualization
To highlight the pricing associated with the virtualization layer, the desktop broker component must be
consistent across hypervisors. XenDesktop virtual desktop infrastructure supports both vSphere and
XenServer. Since VMware® View® does not provide cross-hypervisor support, this example uses
XenDesktop as its desktop broker. When deploying vSphere without View, customers must either
purchase as the Desktop Edition or Enterprise Plus Edition, while XenDesktop includes an entitlement for
XenServer. For this pricing scenario, assume a total of 1,000 desktops are required, vSphere Desktop

Edition is priced at 100 desktops per license and requires a separate vCenter installation from any non-
desktop vCenter instance.
XenServer vSphere
Host license cost Included with XenDesktop 10 Desktop Edition: $65,000
Host Subscription Included with XenDesktop Three years of SnS: $9,750
Support Included with XenDesktop Included with SnS
Management Server
Management subscription Free Three years of SnS: $10,343
Total Free $100,083
Cloud services
As with the desktop virtualization example, a cloud orchestration solution supporting both vSphere and
XenServer is required to provide a fair pricing comparison. Citrix® CloudPlatform™ also includes an
entitlement to XenServer, but to further level the pricing comparison, Apache CloudStack is used.
Apache CloudStack fully supports XenServer and vSphere and provides no entitlements to either.
CloudStack integrates with vSphere using vCenter, and using this model the pricing example is identical
to that of the traditional server virtualization.
XenServer vSphere
Host license cost 20 Sockets: $21,000 20 Enterprise Plus: $71,900
Host subscription and
support
Three years of maintenance: $6,000 Three years of SnS: $52,400
management server
Management subscription Included Three years of SnS: $10,343
Total $27,000 $149,163

Conclusion – The Hypervisor is now a Commodity
Looking back over the history of server virtualization, it is clear that hypervisors were once viewed as a
premium tool to extract the most value from a server. Today, virtualization is mainstream with reportedly
over 50 percent of servers virtualized, and the hypervisor itself has become a commodity. While VMware
may continue in its attempts to maximize the revenue generated by vSphere through complex annual
pricing changes, IT organizations are looking at virtualization as a tool to maximize their efficiency and
effectiveness. Since these two objectives are at odds, IT has been forced to look at alternate options for
virtualization platforms. Considering key features and performance requirements of a virtualization
project together with the overall costs of delivering IT services, XenServer warrants a closer look.
The following table compares features of the two competing products that were discussed in this paper,
plus additional features. Although vSphere is a viable choice for certain workloads, particularly if they are
legacy workloads, or rely on features inherent to a product which has evolved to service environments
which are becoming increasingly rare today, it no longer is the only meaningful hypervisor option. It is for
this reason that datacenter operators globally have adopted a multi-hypervisor approach to operations
and those new workloads are increasingly deployed using XenServer rather than vSphere.
Feature vSphere 5.1 XenServer 6.2
Bare-metal hypervisor Yes Yes
Cluster management Requires vCenter Yes
Highly available cluster
management
Requires vCenter and vCenter
Heartbeat
Yes
Maximum cluster size 32 16
VM density of at least 200 Yes Yes
Shared storage options NFS, iSCSI, HBA, VAAI NFS, iSCSI, HBA, StorageLink
Live storage migration Yes Yes
Local disk cache of templates Yes Yes
Disaster recovery services Requires SRM Yes
Live VM migration Yes Yes
Cross cluster live VM migration Yes Yes
Memory over-commit Page sharing, ballooning, host
page swap
Ballooning
NetFlow Requires virtual distributed
switch
Yes
Port mirroring Requires virtual distributed
switch
RSPAN
IPv6 Yes Yes
Network encapsulation
options
None GRE
High availability for host
infrastructure
Yes Yes
Operating system support Provides support for legacy
versions
Currently supported by vendor
GPU access Virtual GPU Exclusive with full DirectX10 and
OpenGL support

About Citrix
Citrix (NASDAQ:CTXS) is the cloud company that enables mobile workstyles—empowering
people to work and collaborate from anywhere, easily and securely. With market-leading
solutions for mobility, desktop virtualization, cloud networking, cloud platforms, collaboration and
data sharing, Citrix helps organizations achieve the speed and agility necessary to succeed in a
mobile and dynamic world. Citrix products are in use at more than 260,000 organizations and by
over 100 million users globally. Annual revenue in 2012 was $2.59 billion. Learn more
at www.citrix.com.
©2013 Citrix Systems, Inc. All rights reserved. Citrix®
, XenServer®
, XenDesktop®
, XenCenter®
,
Xen®
, XenMotion™ and CloudPlatform™ are trademarks or registered trademarks of Citrix
Systems, Inc. and/or one or more of its subsidiaries, and may be registered in the United States
Patent and Trademark Office and in other countries. All other trademarks and registered
trademarks are property of their respective owners.

Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1

More Related Content

What's hot

Viewers also liked

Similar to Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1

More from Lorscheider Santiago

Recently uploaded

Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1