Page Comparison

Hyper-threading checkbox

Enable the Charon-SSP adaption for a hyper-threading host environment or for running the Charon host under a Hypervisor. With this mode enabled, Charon-SSP does not set a CPU core affinity on the host system, but relies on the scheduler of the host operating system instead. Power option Power save will allow idle guest system CPU threads to be rescheduled.

 If the Charon host runs in the AWS a cloud environment on a non-metal instance type, this option should be enabled.

Number of CPU

Configure the number of virtual SPARC CPUs. Supported number of CPUs:

• Charon-SSP/4M: 1 to 4 virtual SPARC CPUs
• Charon-SSP/4U(+): 1 to 24 virtual CPUs
• Charon-SSP/4V(+): 1 to 64 virtual CPUs

Power options

This option determines the host CPU behavior when the guest Solaris is in idle state.

• Performance
  Choosing this option keeps the host CPU in a busy loop waiting for next Solaris activity. This option offers the best response time in Solaris but the host CPU usage is at 100% all the time.

• Balanced (default)
  Choosing this option allows the host CPU to go into an idle state until the next Solaris activity. This option offers a good balance between Solaris response time and host CPU usage.

• Power save
  The host CPU is in deep “sleep” mode when the guest Solaris is in idle state. With this option and hyper-threading mode set, an idle Solaris guest system CPU thread can be rescheduled.

CPU binding

Assign specific host CPUs to the processing of SPARC instructions. If configured, each virtual SPARC CPU must be assigned to exactly one specific host CPU for instruction processing.

This field consists of a comma-separated list of CPU IDs (index starts from 0). If left blank, the virtual machine software will assign affinity itself starting with the highest CPU ID (recommended). Cannot be used with hyper-threading mode enabled. CPU cores assigned to emulated CPUs are never shared between instances.

I/O binding

Assign specific host CPUs to the processing of virtual machine I/O requests.

This field consists of a comma-separated list of CPU IDs. If left blank, the virtual machine will assign I/O processing affinity itself starting from CPU ID 0 (recommended). CPUs listed here cannot be shared between instances.

 If there is an overlap with manually configured bindings in other instances or the automatically calculated I/O CPU allocations, the instance will not start with the message:
“Wrong IO affinity setting: already allocated by another thread.”

Reserved I/O CPUs

Reserve a number of CPUs on the host system for processing virtual machine I/O requests. Allocation will start from the lowest CPU ID. If neither I/O binding nor Reserved I/O CPUs is set, Charon will assign 1/3 (minimum 1; rounded down) of the number of host CPU cores to I/O processing starting from the lowest CPU ID (recommended). If there is an overlap between a manual configuration in one instance and the automatic calculation of I/O CPUs in other instances, overlapping I/O CPUs are shared between instances.

  If the number of I/O CPU cores (configured or calculated automatically) + the number of emulated CPUs is higher than the number of available host CPU cores, the following error is logged and the emulator does not start:
"Wrong CPU affinity setting: no enough host CPUs."