Go to main content

Oracle® Solaris Cluster Data Service for Oracle VM Server for SPARC Guide

Exit Print View

Updated: June 2017
 
 

Configuration Guidelines

Observe the following configuration guidelines that apply only to HA for Oracle VM Server.

For restrictions that apply to all data services, see the Oracle Solaris Cluster 4.3 Release Notes.

  • HA for Oracle VM Server configuration –Oracle VM Server for SPARC can be configured only as a failover data service and not as a scalable data service. It can be configured only in the global zone.

  • HA for Oracle VM Server virtual disks – The Oracle VM Server for SPARC virtual disk back end can be of any storage or file system that is supported by Oracle Solaris Cluster software. This includes cluster file systems, NFS, iSCSI, and SAN LUNs. The back end is exported through the virtual disk server of the control domain to a domain as a full disk and is visible to the Oracle Solaris installation software inside the logical domain. Virtual disks from non-control domains are not supported.

  • Live migration and cold migration – HA for Oracle VM Server software supports Oracle VM Server for SPARC live migration and cold migration of guest domains that are configured with HA for Oracle VM Server. No other type of logical domain in this data service configuration is supported to use cold migration or live migration.

    Live migration is supported only for cluster file systems (UFS or raw disk), NFS, iSCSI, or SAN LUNs, as live migration requires that storage is accessible to all potential primary nodes simultaneously.

    In some cases where the cluster cannot determine the target node to which the HA for Oracle VM Server resource group is migrating, it uses an ordinary resource group switchover instead of using live migration. In such cases, the logical domain shuts down on its current node and then boots on its new node. To achieve live migration, relocate the HA for Oracle VM Server resource group by using the clresourcegroup switch command explicitly on the resource group, rather than depending on node evacuation or strong resource group affinities to move the resource group.