If uname -p says i386, you’re already on Solaris for x86. Solaris 9, for example, shipped for x86 as well as SPARC. Your applications are x86 binaries, and the route is a virtual machine on a hypervisor that still supports your Solaris release. Most of this page doesn’t apply.
If it says sparc, read on. The uname -m value gives the hardware family, which decides what an emulator has to reproduce:
- sun4m: 32-bit SPARCstation-class systems, such as the SPARCstation 5, 10 and 20. Solaris 9 is the last release that runs on them.
- sun4u: 64-bit UltraSPARC systems, such as the Sun Enterprise and Sun Fire V-series servers.
- sun4v: T-series systems, such as the SPARC T2 and T4, running Solaris 10 or 11.
If file reports a 64-bit binary (SPARCV9), the application needs a 64-bit SPARC system: sun4u or sun4v.
Why a SPARC application won’t run on x86 or Linux
- Different instruction sets. A compiled Solaris application is machine code for SPARC processors, and x86 processors can’t execute it.
- Solaris x86 is a separate build. It runs x86 binaries only. The same source code recompiled for x86 will usually work; the existing SPARC binaries won’t.
- Linux is a different operating system. System calls, libraries, threading and administration differ from Solaris, so moving to Linux means recompiling and adapting the code.
- Byte order. SPARC is big-endian and x86 is little-endian. Code that assumes big-endian order, which is common in binary file handling and network code, works on SPARC and breaks on x86. These bugs tend to surface late, in testing.
| Route | What changes | What you need | Removes SPARC hardware? | Main risk |
|---|
| Port to Linux | Application recompiled or rewritten; operating system changes | Source code, build skills, Linux versions of third-party software, a full retest | Yes | Cost and time; Solaris-specific code and byte-order bugs |
| Recompile for Solaris on x86 | Application recompiled; Solaris stays | Source code, x86 versions of third-party software, a supported Solaris x86 release | Yes | As for porting, on a smaller scale |
| Stay on SPARC with Solaris 11.4 | Hardware refresh and operating system upgrade; older environments in branded zones | Current Oracle SPARC servers; an application that runs on Solaris 11 or in a Solaris 10 branded zone | No | The SPARC dependency, and the datacenter, stay |
| Keep current hardware under third-party maintenance | Nothing | Spare parts and Solaris skills | No | Parts scarcity and failure risk; it only buys time |
| Emulate SPARC on x86 (QEMU or Charon-SSP) | Hardware only; Solaris and the application stay as they are | Disk images of the original system, an x86-64 Linux host, your Solaris licence | Yes | The emulator must support your hardware family and Solaris release; performance must be tested |
On current SPARC hardware, Solaris 11 can host Solaris 10 environments in branded zones, and Solaris 10 hosted Solaris 8 and 9 environments the same way, on SPARC only.
Whatever the route, check the operating system’s support status. Oracle’s Extended Support for Solaris 10 and Solaris 11.3 ends in January 2027, after which they move to Sustaining Support. Solaris 9 and earlier are already beyond Extended Support. Premier Support for Solaris 11.4 runs to November 2031. Emulation replaces the hardware, not the operating system: Solaris 10 running in an emulator is still Solaris 10.
How SPARC emulation works
An emulator is a program that behaves like a SPARC computer. It presents a virtual SPARC processor, memory, disks, network interfaces and a console to the operating system. Solaris boots on it as it would on real hardware, and applications run unchanged. The emulator itself runs as an ordinary process on an x86-64 host.
QEMU: free, open source
QEMU has two SPARC emulators:
- qemu-system-sparc emulates 32-bit sun4m machines, including the SPARCstation 5, 10 and 20. Memory is limited to 2 GB, or 256 MB on the SPARCstation 5 model. QEMU’s documentation notes that “older Solaris kernels don’t work” with its OpenBIOS firmware. Because Solaris 9 is the last release for sun4m, this emulator can’t run Solaris 10 or 11, or 64-bit SPARC applications.
- qemu-system-sparc64 emulates sun4u, sun4v and Niagara (T1) machines. Its documentation lists Linux, NetBSD and OpenBSD as guests. The only Solaris it mentions is a prebuilt Solaris 10 image from the OpenSPARC T1 project, on the Niagara machine, and it describes sun4v emulation as a work in progress.
QEMU has community support only: no vendor, no service levels.
Good for: learning, testing, reading data from old 32-bit Solaris disks, hobby use. Not suited to: production systems, 64-bit Solaris 10 or 11, or anything that needs a support contract.
Charon-SSP: commercial, built for production
Charon-SSP from Stromasys emulates all three SPARC hardware families:
| Product | Hardware Family | Operating systems |
|---|
| Charon-SSP/4M | Sun-4m (SPARCstation 20) | SunOS 4.1.3 to 4.1.4; Solaris 2.3 to Solaris 9 |
| Charon-SSP/4U and 4U+ | Sun-4u, 64-bit SPARC V9 (Sun Enterprise 450) | Solaris 2.5.1 to Solaris 10 |
| Charon-SSP/4V and 4V+ | Sun-4v (SPARC T2, T4) | Solaris 10 from update 4; Solaris 11.1 to 11.4 |
- Compatibility: binary compatible with SPARC hardware, including storage, Ethernet and serial line I/O. Solaris, layered products and applications run without recompiling.
- Host: x86-64 Linux, such as Red Hat Enterprise Linux or Rocky Linux, on a physical server or a virtual machine. It runs on premises or in AWS, Microsoft Azure, Google Cloud and Oracle Cloud Infrastructure.
- Storage and network: the original disks become image files or storage mapped from the host. The Solaris system gets its own network interface; on AWS, that is a secondary network interface with source/destination checking turned off.
- Licensing: a Charon-SSP licence, which on AWS can be billed through AWS Marketplace. You supply the Solaris licence.
- Support: commercial support from Stromasys with defined service levels.
Good for: production systems on any of the three hardware families, 64-bit Solaris 10 and 11, and datacenter exits to the cloud.
What a move to Charon-SSP involves
- Collect system information and workload data using Stromasys data collector for Solaris.
- Install Charon-SSP on an x86-64 Linux host and configure a virtual system of the same hardware family.
- Migrate Solaris OS and data. This step requires Solaris expertise. Stromasys can provide migration automation tools which can speed up the process and lower requirements for Solaris knowledge level.
- Boot Solaris on the virtual system, adjust device and network settings, and test the application.
- Cut over.
Which route fits
- You have the source code, the team, and a reason to change the application anyway: port it to Linux.
- The vendor is gone, the source is lost, or the system is certified as it stands: emulate. For production, use Charon-SSP.
- You only need to read old data or try something on a 32-bit Solaris system: QEMU may be enough.
- You need to leave the datacenter: port, or emulate in the cloud. Staying on SPARC doesn’t get you out.
- You’re already on Solaris 11.4 with current SPARC hardware: staying may be the cheapest route.
When emulation is the wrong choice
- The application depends on hardware an emulator doesn’t reproduce, such as custom SBus or PCI cards.
- The workload needs the full speed of a recent SPARC server. Emulation suits older systems best. Test performance before committing.
- The application will be retired soon. Keeping the current hardware running until then may cost less.
- You need Oracle to support the operating system beyond its end dates. Emulation doesn’t change Solaris’s support status.