|
|
|
VM Mobility |
|
|
|
Live Migration of VMs
Details
|
Yes - Live Migration
There is also a possibility to use SSL to encryption the Live Migration. More info on: http://docs.oracle.com/cd/E50245_01/index.html
|
Yes vMotion
- Cross vSwitch vMotion Only
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)
|
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.
|
|
|
Migration Compatibility
Details
|
Yes
On the same Cluster/Server Pool it is possible to separate the Cluster/Server Pool Members based on the CPU Family to guarantee the success of Live Migration between those Servers but there is no possibility of grouping different CPUs generations by masking out incompatible functions using CPU Masking. More info on: http://docs.oracle.com/cd/E50245_01/index.html
|
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
|
Yes (Heterogeneous Pools)
XenServer 5.6 introduced 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.x
|
|
|
|
Yes - Maintenance Mode
It is possible to execute the Maintenance Mode and It is also possible to Lock some Servers to not receive this Offload from the Server that is entering in this State. More info on: http://docs.oracle.com/cd/E50245_01/index.html
|
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.
|
Yes
Enabled through XenCenter
|
|
|
Automated Live Migration
Details
|
Yes
Oracle VM provides a DRS feature for the following constraints: (CPU-CPU, N:Network i/o) during VMs runtime and the following constraints: (CPU-CPU, N:Network i/o, MEM:Memory) during VMs startup. More info on: http://docs.oracle.com/cd/E50245_01/index.html
|
No
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.
|
No, Workload Balancing
Workload Balancing (WLB) which was reintroduced in 6.5 is now enhanced with XenServer 7.x. Available in Enterprise edition.
|
|
|
|
Yes
Oracle VM provides a DPM feature that works with IPMI and Wake Up On Lan. More info on: http://docs.oracle.com/cd/E50245_01/index.html
|
No
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.
|
No Workload Balancing
Power management is part of XenServer Workload Balancing (WLB) available in Enterprise edition.
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.
|
|
|
Storage Migration
Details
|
Yes
Oracle VM provides a capability to Migrate the VM Disks to different Storage Repositories (not live). More info on: http://docs.oracle.com/cd/E50245_01/index.html
|
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.
|
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
|
|
|
|
HA/DR |
|
|
|
|
32 Hosts in Cluster/Pool
Oracle VM can have up to 32 Servers on each Clustered Server Pool and up to 64 Servers on each Unclustered Server Pool. More info on: http://docs.oracle.com/cd/E50245_01/index.html
|
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
|
16 hosts / resource pool
16 Hosts per Resource Pool.
Please see XenServer 7.1 Configuration Limits document http://bit.ly/2mpocPc
|
|
|
Integrated HA (Restart vm)
Details
|
Yes - Clustered Pool
Oracle VM will restart HA-enabled Guests on remaining Hosts in case of Host failure. More info on: http://docs.oracle.com/cd/E50245_01/index.html
|
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).
|
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).
|
|
|
Automatic VM Reset
Details
|
Yes
Oracle VM will restart Guests on the same Host due to OS Failures. More info on: http://docs.oracle.com/cd/E50245_01/index.html
|
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.
|
No
There is no automated restart/reset of individual virtual machines e.g. to protect against OS failure
|
|
|
VM Lockstep Protection
Details
|
No
|
Yes (Fault Tolerance) 2 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.
|
No
While XenServer can perform VM restart in case of a host failure there is no integrated mechanism to provide zero downtime failover functionality.
|
|
|
Application/Service HA
Details
|
No
|
No
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.
|
No
There is no application monitoring/restart capability provided with XenServer
|
|
|
Replication / Site Failover
Details
|
Yes
If the Storage is Replicated the whole environment can be orchestrated to be up and running in minutes if the Failover Site already has the Oracle VM up and running pointing to the Replicated Storage with the help of Oracle Site Guard. More info on: http://www.oracle.com/technetwork/server-storage/vm/ovm3-disaster-recovery-1872591.pdf
|
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.
|
Integrated Disaster Recovery (no storage array control)
XenServer 6 introduced the new Integrated Site Recovery (maintained in 7.0), 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.
|
