|
|
|
VM Mobility |
|
|
|
Live Migration of VMs
Details
|
Yes XenMotion
XenMotion is available in all versions of XenServer and allows you to move a running VM from one host to another host, when the VMs disks are located on storage shared by both hosts. This allows for pool maintenance features such as Workload Balancing (WLB), High Availability (HA), and Rolling Pool Upgrade (RPU) to automatically move VMs. These features allow for workload leveling, infrastructure resilience, and the upgrade of server software, without any VM downtime. Storage can only be shared between hosts in the same pool, as a result, VMs can only be moved within the same pool.
|
Yes (vMotion)
vMotion
- Cross vSwitch vMotion (all versions)
- Cross vCenter vMotion (n/a for Standard)
- Long Distance vMotion (n/a for Standard)
- Cross Cloud vMotion (n/a for Standard)
- Encryption vMotion (n/a for Standard)
|
=CR26
|
|
|
Migration Compatibility
Details
|
Yes (Heterogeneous Pools)
XenServer 7.0 introduced improved support for Heterogeneous Pools which enables live migration across different CPU types of the same vendor (requires AMD Extended Migration or Intel Flex Migration), details here: http://bit.ly/1ADu7Py.
This capability is maintained in XenServer 7.1
|
Yes (EVC)
Enhanced vMotion Compatibility - enabled on vCenter cluster-level, utilizes Intel FlexMigration or AMD-V Extended Migration functionality available with most newer CPUs (but cannot migrate between Intel and AMD), Details here: http://kb.vmware.com/kb/1005764
|
=CR27
|
|
|
|
Yes
Enabled through XenCenter
|
Yes
NEW
Maintenance mode is a core feature to prepare a host to be shut down safely.
vSphere 6.5: Faster Maintenance Mode and Evacuation Updates.
|
=CR28
|
|
|
Automated Live Migration
Details
|
Yes Workload Balancing
NEW
Workload Balancing (WLB) which was reintroduced in 6.5 is now enhanced with XenServer 7.0.
Workload Balancing 7.1 is supported on XenServer 7.x, 6.5 and includes the following enhanced features:
- Host disk Read/Write I/O. Introduces host disk Read/Write I/O recommendations for workload optimization to complement the existing CPU, memory, and network load balancing capabilities
- CentOS 7.2. Workload Balancing VPX is based on 64-bit CentOS 7.2
Details here: http://bit.ly/2mrYNVo
|
Yes (DRS) - CPU, Mem
NEW
vSphere 6.5
VM Distribution: Enforce an even distribution of VMs.
Memory Metric for Load Balancing: DRS uses Active memory + 25% as its primary metric.
CPU over-commitment: This is an option to enforce a maximum vCPU:pCPU ratios in the cluster.
Network Aware DRS - system look at the network bandwidth on the host when considering making migration recommendations.
Storage IO Control configuration is now performed using Storage Policies and IO limits enforced using vSphere APIs for IO Filtering (VAIO).
Storage Based Policy Management (SPBM) framework, administrators can define different policies with different IO limits, and then assign VMs to those policies.
|
=CR29
|
|
|
|
Yes Workload Balancing
NEW
Power management is part of XenServer Workload Balancing (WLB). More inf: http://bit.ly/2mrYNVo
Background: Power Management introduced with 5.6 was able to automatically consolidate workloads on the lowest possible number of physical servers and power off unused hosts when their capacity is not needed. Hosts would be automatically powered back on when needed.
|
Yes (DPM)
Distributed Power Management - enables to consolidate virtual machines onto fewer hosts and power down unused capacity - reducing power and cooling. This can be fully automated where servers are powered off when not needed and powered back on when workload increases.
|
=CR30
|
|
|
Storage Migration
Details
|
Yes (Storage XenMotion)
NEW
Storage XenMotion in XenServer 7.x now works with the VM in any power state (stopped, paused or running)
XenServer 6.1 introduced the long awaited (live) Storage XenMotion capability
Storage XenMotion allows storage allocation changes while VMs are running or moved from one host to another including scenarios where a) VMs are NOT located on storage shared between the hosts (shared nothing live migration) and (b) hosts are not even in the same resource pool. This enables system administrators to:
- Live migration of a VM disk across shared storage targets within a resource pool (e.g. move between LUNs when one is at capacity);
- Live migration of a VM disk from one storage type to another storage type within a resource pool (e.g. perform storage array upgrades)
- Live migration of a VM disk to or from local storage on a XenServer host within a resource pool (reduce deployment costs by using local storage)
- Rebalance or move VMs between XenServer pools (for example moving a VM from a development environment to a production environment);
Starting with XenServer 6.1, administrators initiating XenMotion and Storage XenMotion operations can specify which management interface
transfers should occur over. Through the use of multiple management interfaces, the virtual disk transfer can occur with less impact on both core XenServer operations and VM network utilization.
Citrix supports up to 3 concurrent Storage XenMotion operations. The maximum number for (non-CDROM) VDIs per VM = six. Allowed Snapshots per VM undergoing Storage XenMotion = 1.
Technical details here: http://bit.ly/2lNgACU
|
Yes (Live Storage vMotion)
Storage vMotion allows to perform live migration of virtual machine disk files (e.g. across heterogeneous storage arrays) without vm downtime. Storage DRS handles initial vmdk placement and gives migration recommendations to avoid I/O and space utilization bottlenecks on the datastores in the cluster. The migration is performed using storage vMotion.
|
=CR31
|
|
|
|
HA/DR |
|
|
|
|
16 hosts / resource pool
16 Hosts per Resource Pool.
Please see XenServer 7.1 Configuration Limits document http://bit.ly/2mpocPc
|
max 64 nodes / 8000 vm per cluster
Up to 64 nodes can be in a DRS/HA cluster, with a maximum of 8000 vm/cluster
|
=CR32
|
|
|
Integrated HA (Restart vm)
Details
|
Yes
XenServer High Availability protects the resource pool against host failures by restarting virtual machine. HA allows for configuration of restart priority and failover capacity. Configuration of HA is simple (effort similar to enabling VMware HA).
|
Yes (VMware HA)
NEW
vSphere 6.5 Proactive HA detect hw condition evacuate host before failure (plugin provided OEM vendors)
Quarantine mode - host is placed in quarantine mode if it is considered in degraded state
Simplified vSphere HA Admission Control - 'Percentage of Cluster Resources' admission control policy
vSphere 6.0
- Support for Virtual Volumes – With Virtual Volumes a new type of storage entity is introduced in vSphere 6.0.
- VM Component Protection – This allows HA to respond to a scenario where the connection to the virtual machine’s datastore is impacted temporarily or permanently.
“Response for Datastore with All Paths Down”
“Response for Datastore with Permanent Device Loss”
- Increased scale – Cluster limit has grown from 32 to 64 hosts and to a max of 8000 VMs per cluster
- Registration of “HA Disabled” VMs on hosts after failure.
VMware HA restarts virtual machines according to defined restart priorities and monitors capacity needs required for defined level of failover.
vSphere HA in vSphere 5.5 has been enhanced to conform with virtual machine-virtual machine anti-affinity rules. Application availability is maintained by controlling the placement of virtual machines recovered by vSphere HA without migration. This capability is configured as an advanced option in vSphere 5.5.
vSphere 5.5 also improved the support for virtual Microsoft Failover Clustering (cluster nodes in virtual machines) - note that this functionality is independent of VMware HA and requires the appropriate Microsoft OS license and configuration of a Microsoft Failover Cluster. Microsoft clusters running on vSphere 5.5 now support Microsoft Windows Server 2012, round-robin path policy for shared storage, and iSCSI and Fibre Channel over Ethernet (FCoE) for shared storage.
While not obvious to the user - with vSphere 5, HA has been re-written from ground-up, greatly reducing configuration and failover time. It now uses a one master - all other slaves concept. HA now also uses storage path monitoring to determine host health and state (e.g. useful for stretched cluster configurations).
|
=CR33
|
|
|
Automatic VM Reset
Details
|
No
There is no automated restart/reset of individual virtual machines e.g. to protect against OS failure
|
Yes (VMware HA)
NEW
vSphere 6.5 - Orchestrated Restart - VMware has enforced the VM to VM dependency chain, for a multi-tier application installed across multiple VMs.
Uses heartbeat monitoring to reset unresponsive virtual machines.
|
=CR34
|
|
|
VM Lockstep Protection
Details
|
No
While XenServer can perform vm restarts in case of a host failure there is no integrated mechanism to provide zero downtime failover functionality.
|
Yes (Fault Tolerance) 4 vCPUs.
NEW
vSphere 6.5 FT has more integration with DRS and enhanced Network (lower the network latency)
Fault Tolerance brings continuous availability protection for VMs with up to 4 vCPUs in Enterprise Plus and Standard is 2 vCPUs.
Uses a shadow secondary virtual machine to run in lock-step with primary virtual machine to provide zero downtime protection in case of host failure.
|
=CR35
|
|
|
Application/Service HA
Details
|
No
There is no application monitoring/restart capability provided with XenServer
|
App HA
vSphere 6.5 Proactive HA detect hw condition evacuate host before failure (plugin provided OEM vendors)
Quarantine mode - host is placed in quarantine mode if it is considered in degraded state
Simplified vSphere HA Admission Control - 'Percentage of Cluster Resources' admission control policy
VMware HA restarts virtual machines according to defined restart priorities and monitors capacity needs required for defined level of failover.
|
=CR36
|
|
|
Replication / Site Failover
Details
|
Integrated Disaster Recovery (no storage array control)
XenServer 6 introduced the new Integrated Site Recovery (maintained in 7.1), replacing the StorageLink Gateway Site Recovery used in previous versions. It utilizes the native remote data replication between physical storage arrays and automates the recovery and failback capabilities. The new approach removes the Windows VM requirement for the StorageLink Gateway components and it works now with any iSCSI or Hardware HBA storage repository (rather only the restricted storage options with StorageLink support). You can perform failover, failback and test failover. You can configure and operate it using the Disaster Recovery option in XenCenter. Please note however that Site Recovery does NOT interact with the Storage array, so you will have to e.g. manually break mirror relationships before failing over. You will need to ensure that the virtual disks as well as the pool meta data (containing all the configuration data required to recreate your vims and vApps) are correctly replicated to your secondary site.
|
Yes (vSphere Replication)
DR Orchestration (Vendor Add-On: VMware SRM)
NEW
vSphere Replication is VMware’s proprietary hypervisor-based replication engine designed to protect running virtual machines from partial or complete site failures by replicating their VMDK disk files.
This version extends support for the 5 minute RPO setting to the following new data stores: VMFS 5, VMFS 6, NFS 4.1, NFS 3, VVOL and VSAN 6.5.
|
=CR37
|
