Supported hardware
SPARC hypervisors run in hyperprivileged execution mode, which was introduced in the sun4v architecture. The sun4v processors released as of 2017 are the Sun/Oracle UltraSPARC T1, T2, T2+, T3,3 T4,4 T5, M5, M6, M7, S7, and M8 and Fujitsu SPARC64 X, X+, XIfx, and XII. Systems based on UltraSPARC T1 support only Logical Domains versions 1.0-1.2.5 The newer types of T-series servers support both older Logical Domains and newer Oracle VM Server for SPARC product version 2.0 and later. These include:
UltraSPARC T1-based:
- Sun / Fujitsu SPARC Enterprise T1000 and T2000 servers
- Sun Fire T1000 and T2000 servers
- Netra T2000 Server
- Netra CP3060 Blade
- Sun Blade T6300 Server Module
UltraSPARC T2-based:
- Sun / Fujitsu SPARC Enterprise T5120 and T5220 servers
- Sun Blade T6320 Server Module
- Netra CP3260 Blade
- Netra T5220 Rackmount Server
UltraSPARC T2 Plus systems:
- Sun / Fujitsu SPARC Enterprise T5140 and T5240 servers (2 sockets)
- Sun / Fujitsu SPARC Enterprise T5440 (4 sockets)
- Sun Blade T6340 Server Module (2 sockets)
SPARC T3 systems:6
- Sun / Fujitsu SPARC T3-1 servers (1 socket)
- Sun SPARC T3-1B Server Module (1 socket)
- Sun / Fujitsu SPARC T3-2 servers (2 sockets)
- Sun / Fujitsu SPARC T3-4 servers (4 sockets)
SPARC T4 systems4
- SPARC T4-1 Server (1 socket)
- SPARC T4-1B Server Module (blade)
- SPARC T4-2 Server (2 sockets)
- SPARC T4-4 Server (4 sockets)
SPARC T5 systems7
- SPARC T5-1B Server Module (blade)
- SPARC T5-2 Server (2 sockets)
- SPARC T5-4 Server (4 sockets)
- SPARC T5-8 Server (8 sockets)
SPARC T7 systems,8 which use the same SPARC M7 processor as the M7-8 and M7-16 servers listed below.
- SPARC T7-1 (1 CPU socket)
- SPARC T7-2 (2 CPU sockets)
- SPARC T7-4 (4 CPU sockets)
SPARC M-Series systems9710
- Oracle SPARC M5-32 Server (32 sockets)
- Oracle SPARC M6-32 Server (32 sockets)
- Fujitsu M10-1 (1 socket)
- Fujitsu M10-4 (4 sockets)
- Fujitsu M10-4S (64 sockets)
- Oracle SPARC M7-8 (8 CPU sockets)
- Oracle SPARC M7-16 (16 CPU sockets)
Technically, the virtualization product consists of two interdependent components: the hypervisor in the SPARC server firmware and the Logical Domains Manager software installed on the Solaris operating system running within the control domain (see Logical Domain roles, below). Because of this, each particular version of Logical Domains (Oracle VM Server for SPARC) software requires a certain minimum version of the hypervisor to be installed into the server firmware.
Logical Domains exploits the chip multithreading (CMT) nature of the "CoolThreads" processors. A single chip contains up to 32 CPU cores, and each core has either four hardware threads (for the UltraSPARC T1) or eight hardware threads (for the UltraSPARC T2/T2+, and SPARC T3/T4 and later) that act as virtual CPUs. All CPU cores execute instructions concurrently, and each core switches between threads—typically when a thread stalls on a cache miss or goes idle—within a single clock cycle. This lets the processor gain throughput that is lost during cache misses in conventional CPU designs. Each domain is assigned its own CPU threads and executes CPU instructions at native speed, avoiding the virtualization overhead for privileged operation trap-and-emulate or binary rewrite typical of most VM designs.
Each server can support as many as one domain per hardware thread up to a maximum of 128. That's up to 32 domains for the UltraSPARC T1, 64 domains for the UltraSPARC T2 and SPARC T4-1, and 128 domains for UltraSPARC T3 as examples single-processor (single-socket) servers. Servers with 2-4 UltraSPARC T2+ or 2-8 SPARC T3-T5 CPUs support as many logical domains as the number of processors multiplied by the number of threads of each CPU up to the limit of 128.11 M-series servers can be subdivided into physical domains ("PDoms"), each of which can host up to 128 logical domains. Typically, a given domain is assigned multiple CPU threads or CPU cores for additional capacity within a single OS instance. CPU threads, RAM, and virtual I/O devices can be added to or removed from a domain by administrator issuing command in the control domain. This change takes effect immediately without the need to reboot the affected domain, which can immediately make use of added CPU threads or continue operating with reduced resources.
When hosts are connected to shared storage (SAN or NAS), running guest domains can be securely live migrated between servers without outage (starting with Oracle VM Server for SPARC version 2.1). The process encrypts guest VM memory contents before they are transmitted between servers, using cryptographic accelerators available on all processors with sun4v architecture.
Logical Domain roles
All logical domains are the same except for the roles that they are assigned. There are multiple roles that logical domains can perform such as:
- Control domain
- Service domain
- I/O domain
- Root domain
- Guest domain
Control domain, as its name implies, controls the logical domain environment. It is used to configure machine resources and guest domains, and provides services necessary for domain operation, such as virtual console service. The control domain also normally acts as a service domain.
Service domains present virtual services, such as virtual disk drives and network switches, to other domains. In most cases, guest domains perform I/O via bridged access through services domains, which are usually I/O domains and directly connected to the physical devices. Service domains can provide virtual LANs and SANs as well as bridge through to physical devices. Disk images can reside on complete local physical disks, shared SAN block devices, their slices, or even on files contained on a local UFS or ZFS file system, or on a shared NFS export or iSCSI target.
Control and service functions can be combined within domains, however it is recommended that user applications not run within control or service domains in order to protect domain stability and performance.
I/O domains have direct ownership of a PCI bus, or card on a bus, or Single Root I/O Virtualization (SR-IOV) function, providing direct access to physical I/O devices, such as a network card in a PCI controller. An I/O domain may use its devices to have native I/O performance its own applications, or act as a service domain and share the devices to other domains as virtual devices.
Root domains have direct ownership of PCIe "root complex" and all associated PCIe slots. This can be used to grant access to physical I/O devices. A root domain is also an I/O domain. There are a maximum of two root domains for the UltraSPARC T1 (Niagara) servers, one of which also must be the control domain. UltraSPARC T2 Plus, SPARC T3, and SPARC T4 servers can have as many as 4 root domains, limited by the number of PCIe root complexes installed on the server. SPARC T5 servers can have up to 16 root complex domains. Multiple I/O domains can be configured to provide resiliency against failures.
