Content

Cloud Instance Prerequisites for Charon

The cloud instance for running a Charon emulator is also called the Charon host. When creating a cloud instance for Charon, there are hardware and software prerequisites.

Hardware prerequisites of a cloud instance:

For a cloud instance, the hardware characteristics of the instance (e.g., how many CPU cores and how much memory your virtual Charon host system will have) are defined by selecting an instance type or shape. This determines the virtual hardware that will be used for the Charon host instance in the cloud.

Software prerequisites of a cloud instance:

If you use a Charon marketplace image to launch your instance, all Linux host operating system requirements are fulfilled. For conventional emulator installations, the Charon host cloud instance must be based on a supported Linux version.

Cloud Instance Software Prerequisites Overview

This section provides a basic overview of supported Linux distributions and versions for the current versions of the different emulator products (at the time of writing).

Please always refer to the Charon emulator documentation of your emulator product and version for details and up-to-date information.

Only 64-bit versions of Linux are supported.

⁽¹⁾ Linux version 8.10 is supported starting with Charon-SSP 6.0.2, Linux version 9.4 is supported starting with Charon-SSP 6.0.1.
⁽²⁾ CentOS is EOL and not recommended for new deployments.

Cloud Instance Hardware Prerequisites Overview

The sections below provided an overview of basic hardware prerequisites for the different emulator products. Please note the following points regarding the sizing guidelines:

• The sizing information below—in particular regarding number of host CPU cores and host memory—show the minimum requirements.
• Every deployment situation must be reviewed and the actual host sizing has to be adapted as necessary.
• In a hyper-threading environment, for best performance, the number of CPU cores (i.e., real/physical CPUs) should be sufficient to fulfill CPU requirements of the active emulators, thus avoiding high-workload threads sharing one physical CPU core. If possible, hyper-threading should be disabled.

Please always refer to the Charon emulator documentation of your emulator product and version for details and up-to-date information.

Hardware Prerequisites for Charon-SSP Cloud Host Instances

Charon-SSP General Notes

Please note the following points regarding the sizing guidelines:

• The sizing guidelines below—in particular regarding number of host CPU cores and host memory—show the minimum requirements.
  Every deployment situation must be reviewed and the actual host sizing has to be adapted as necessary. For example, the number of CPU cores available for I/O must be increased if the guest applications produce a high I/O load. Also, a system with many emulated CPUs is typically able to create a higher I/O load and thus the number of CPU cores available for I/O may have to be increased. In a hyper-threading environment, for best performance, the number of CPU cores (i.e., real/physical CPUs) should be sufficient to fulfill CPU requirements of the active emulators, thus avoiding high-workload threads sharing one physical CPU core.

• The CPU core allocation for emulated CPUs and CPU cores for I/O processing is determined by the configuration. See CPU Configuration in the general Charon-SSP User's Guide for more information about this and the default allocation of CPU cores for I/O processing.

Important general information:

• To facilitate a fast transfer of emulator data from one cloud instance to another, it is strongly recommended to store all relevant emulator data on a separate disk volume that can easily be detached from the old instance and attached to a new instance.
• Please make sure to dimension your instance correctly from the beginning (check the minimum requirements below). The Charon-SSP license for Charon-SSP AL is created when the instance is first launched. Changing later to another instance size/type and thereby changing the number of CPU cores will invalidate the license and thus prevent Charon instances from starting (new instance required). If planning to use the Charon-SSP AL instance in AutoVE mode, be sure to include the AutoVE server information before first launch, otherwise the public license servers will be used. The license for Charon-SSP VE is created based on the fingerprint taken on the license server. If the license server is run directly on the emulator host and the emulator host later requires, for example, a change in the number of CPU cores, the license will be invalidated, unless it is transferred out of the system beforehand - then the resulting transfer file and a new C2V file from the changed system can be used to obtain a new license from Stromasys.

Charon-SSP Cloud Instance Prerequisites

General CPU requirements: Charon-SSP requires modern x86-64 architecture processors. This could be Intel Servers based on Haswell v3 processors or later, or Desktop Core I7 (CPU frequency at least 3.0 GHz). AMD processors of the same or higher performance are also supported.

Minimum requirements for Charon-SSP:

• Minimum number of host system CPU cores:
  • At least one CPU core for the host operating system, plus:
  • For each emulated SPARC system:
    • One CPU core for each emulated CPU of the instance, plus:
    • At least one additional CPU core for I/O processing (at least two, if server JIT optimization is used). See the CPU Configuration section mentioned above for configuration options. By default, Charon will assign 1/3 (min. 1; rounded down) of the number of CPUs visible to the Charon host to I/O processing.

• Minimum memory requirements:

  • 4GB or more of RAM for the Linux host operating system. The actual requirements may be higher and will depend on the requirements of the non-emulator services running on the Linux host. The previous recommendation of at least 2GB of RAM for the Linux host will still be valid for many systems, but the increasing requirements of the Linux operating system and applications have led to the updated recommendation for new installations. Plus:

  • For each emulated SPARC system:
    • The configured memory of the emulated instance, plus:
    • 2GB of RAM (6GB of RAM if server JIT is used) to allow for DIT optimization, emulator requirements, run-time buffers, SMP and graphics emulation.
• If hyper-threading is enabled on modern x86-64 CPUs, two threads can run on one physical CPU core providing two logical CPUs to the host operating system. If possible, disable hyper-threading on the Charon-SSP host. However, this is frequently not possible in VMware and cloud environments, or it is unclear whether hyper-threading is used or not. The Charon-SSP hyper-threading option enables Charon-SSP to adapt to such environments unless MMU pass-through is used. See the CPU Configuration section in your general Charon-SSP User's Guide mentioned above for detailed configuration information. Please note: for best performance, Charon-SSP threads should not share a physical CPU core – enough physical cores should be available on the host system to satisfy the requirements of the configured emulator(s).
• One or more network interfaces, depending on customer requirements.
• Charon-SSP/4U+ and Charon-SSP/4V+ must run on physical hardware supporting Intel VT-x/EPT or AMD-v/NPT (baremetal instances) and therefore cannot run in all cloud environments. Please check your cloud provider's documentation for the availability of such hardware. In cloud environments, MMU pass-through is recommended instead to achieve comparable performance gains.
  In addition, note the following points:
  
  • MMU pass-through, Charon-SSP/4U+ and Charon-SSP/4V+ are only available when using a Linux kernel supported by Stromasys. Please refer to the general Charon-SSP user's guide for details (see Charon-SSP for Linux).
    
  • The Charon-SSP Plus versions require the SSP+ license upgrade.

Hardware Prerequisites for Charon-AXP Cloud Host Instances

Charon-AXP Number of CPU Cores and CPU Speed

Each Charon-AXP emulated CPU requires a corresponding physical core. So the total number of the host CPUs must exceed the number of emulated CPUs since some of the host CPUs must be dedicated to serving CHaron I/O operations and host operating system needs. If several Charon instances run in parallel, the required number of CPU cores is cumulative.

The following table lists the minimum and recommended number of CPUs required for each virtual HP Alpha instance (note that each Charon instance is able to run on 2 CPU cores hosts, but this configuration does not support emulation of all the virtual CPUs):

When starting, the Charon-AXP software checks the available number of host CPU cores. This check is based on the maximum number of AXP CPUs that can be emulated if this number is not restricted by the n_of_cpus parameter. If the available number of host CPU cores is below this number, Charon-AXP will issue a warning message even if the requirements for the configured number of AXP CPUs are fulfilled. The Charon-AXP software will work despite this warning if the requirements for the configured number of AXP CPUs are fulfilled.

Hyper-threading must be switched off completely. Normally, hyper-threading is disabled in the BIOS settings. In cloud environments, it depends on the cloud provider if and how the number of vCPUs per core can be limited to one. 

CPU speed: the general recommendation is that a higher CPU frequency will lead to better performance of the emulated HP Alpha system. The minimum recommendation is at least 3 GHz.

Charon-AXP Memory Requirements

Minimum host memory size:

• It depends on the amount of Alpha memory to be emulated and on the number of Charon-AXP instances to be run on one host.

• It is calculated using the following formula:
  Minimum host memory = (2GB +  the amount of HP Alpha memory emulated) per Charon-AXP instance

Charon-AXP Disk Storage

The instance needs sufficient disk space for the host and guest operating system and all the emulated storage devices of the legacy system.
To facilitate a fast transfer of emulator data from one cloud instance to another, it is strongly recommended to store all relevant emulator data on a separate disk volume that can easily be detached from the old instance and attached to a new instance

Charon-AXP Ethernet Adapters

Charon- AXP networking requires one of the following:

• One or more dedicated host Ethernet adapters; their number must be equal to the emulated adapters to be configured in Charon-AXP. One adapter must be available to the host for TCP/IP networking, management interface, etc. For this option, you must take into account the cloud-typical restrictions when using dedicated network adapters (e.g., IP unicast only, MAC must not be changed, cloud-provided IP address must be used by guest). Please refer to your cloud-providers documentation and the section Charon Cloud Networking Information in this guide.
• Virtual network interfaces connected to a local bridge configured inside the Charon host.

Hardware Prerequisites for Charon-VAX Cloud Host Instances

Charon-VAX Number of CPU Cores and CPU Speed

Each CHARON emulated CPU requires a corresponding physical core. So the total number of the host CPUs must exceed the number of emulated CPUs since some of the host CPUs must be dedicated to serving CHARON I/O operations and host operating system needs. If several CHARON instances run in parallel, the required number of CPU cores is cumulative.

The table below lists the minimum and recommended number of CPUs required for each product:

When starting, the CHARON-VAX software checks the available number of host CPU cores. This check is based on the maximum number of VAX CPUs that can be emulated. Therefore the number of host CPU cores recommended for the maximum number of emulated CPUs - as shown in the right column of the table above - must be available. If the available number of host CPU cores is below this number, CHARON-VAX will issue a warning message. The CHARON-VAX software will work despite this warning.

Hyper-threading must be switched off completely if possible. Normally, hyper-threading is disabled in the BIOS settings. In cloud environments, it depends on the cloud provider if and how the number of vCPUs per core can be limited to one. 

CPU type and speed:

• Since Charon-VAX utilizes the LAHF instruction in VAX CPU emulation don't use early AMD64 and Intel 64 CPUs in a Charon host system since they do not support this instruction. AMD introduced the instruction with their Athlon 64, Opteron and Turion 64 revision D processors in March 2005 and Intel introduced it with the Pentium 4 G1 stepping in December 2005.
• CPU speed: the general recommendation is that the higher the CPU frequency is, the better the emulated VAX performances will be. The minimum recommendation is at least 3 GHz.

Charon-VAX Memory Requirements

Minimum host memory size:

• It depends on the amount of VAX memory to be emulated and on the number of Charon-VAX instances to be run on one host.

• It is calculated using the following formula:
  Minimum host memory = (2GB +  the amount of VAX memory emulated) per Charon-VAX instance

The maximum amount of VAX memory that can be created in the CHARON-VAX/66x0 products and supported by OpenVMS/VAX is 3584 Mb.

Charon-VAX Disk Storage

The total amount of disk space required for Charon-VAX can be calculated as a sum of all the disk/tape image sizes plus 50 MB for the Charon software plus the space required for the host operating system. Temporary disk storage is often needed when setting up a new virtual machine (for source disks backups storage, software installation kits, etc...).

When virtual disks/tapes are used to represent physical disk drives / magnetic tapes, the disk/tape image files have the same size as their hardware equivalent, regardless of their degree of utilization.

Charon-VAX Ethernet Adapters

Charon- VAX networking requires one of the following:

• One or more dedicated host Ethernet adapters; their number must be equal to the emulated adapters to be configured in Charon-VAX. One adapter must be available to the host for TCP/IP networking, management interface, etc. For this option, you must take into account the cloud-typical restrictions when using dedicated network adapters (e.g., IP unicast only, MAC must not be changed, cloud-provided IP address must be used by guest). Please refer to your cloud-providers documentation and the section Charon Cloud Networking Information in this guide.
• Virtual network interfaces connected to a local bridge configured inside the Charon host.

Hardware Prerequisites for Charon-PAR Cloud Host Instances

The host hardware on which Charon-PAR runs must fulfill at least the following requirements:

• Intel or AMD x86-64 hardware platform (AMD support starting with Charon-PAR version 3.0.6)
• At least 3GHz, 3.4GHz or higher is recommended
• SSE 4.2 and FMA required
• CPU cores required:
  • at least one CPU core for the host operating system, and
  • at least 2 cores per emulated CPU (3 cores for future advanced DIT)
• RAM requirements:
  • 4GB RAM plus 1.1 times the emulated RAM size for the emulator. Additional memory is required for I/O buffering and other Linux processes (2 to 4 GB can be used as a starting point).
  • at least 24GB RAM for N4000 models
• One Ethernet interface for the host system and one Ethernet interface for each emulated Ethernet NIC. Alternatively, TAP interfaces can be used. Please note that the use of TAP interfaces is restricted to internal bridges in cloud environments (that is, a bridge cannot be linked to a NIC connected to the cloud LAN).
• At least one available USB port if HASP hardware licenses are to be used.
• Disable NUMA balancing.
  • To check the status, use the command: cat /proc/sys/kernel/numa_balancing (0 = off, 1 = on).
  • To disable NUMA balancing temporarily, use the command: sysctl -w kernel.numa_balancing=0
  • To make the configuration permanent you must create a sysctl configuration entry:
    • Create a file in /etc/sysctl.d/ (e.g., 90-numa.conf)
    • Add the line kernel.numa_balancing=0
    • Please note: it still works to add the line kernel.numa_balancing=0 directly to /etc/sysctl.conf but this file has been deprecated in newer Linux versions.

• If possible in your cloud environment, restrict the number of vCPUs on each CPU core to one (no hyper-threading).

Please note:

• The sizing guidelines above—in particular regarding number of host CPU cores and host memory—show the minimum requirements. Every use case has to be reviewed and the actual host sizing has to be adapted as necessary.
• If the host CPU does not support the required extensions (SSE and FMA), the emulator will not start. Instead, it will stop with an error message indicating the missing features.
• To identify the capabilities of the host system CPU, use one of the following commands: lscpu or cat /proc/cpuinfo.

Hyper-Threading on Cloud Instances

Some emulator products require that hyper-threading (two threads per physical CPU Core) be disabled. Normally, this is handled via the system BIOS. However, not all cloud providers offer an easy way to configure an instance without hyper-threading. In such cases, it may be necessary to perform an equivalent configuration on the Linux level.

Cloud-specific options:

• AWS: the threads per CPU core can be configured. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-specify-cpu-options.html
• GCP: the threads per CPU core can be configured. See https://cloud.google.com/compute/docs/instances/set-threads-per-core
• Azure: manual configuration on the Linux level
• OCI: manual configuration on the Linux level
• IBM: manual configuration on the Linux level. See https://cloud.ibm.com/docs/vpc?topic=vpc-disabling-hyper-threading

Basic steps of a manual configuration on the Linux level:

Please note: not all cloud instances may support disabling hyper-threading. Please refer to your cloud providers documentation.

• Check if hyper-threading is enabled on your system. If the lscpu command shows two threads per core then hyper-threading is on. Example:

  $ lscpu
  Architecture:            x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Address sizes:         39 bits physical, 48 bits virtual
    Byte Order:            Little Endian
  CPU(s):                  8
    On-line CPU(s) list:   0-7
  Vendor ID:               GenuineIntel
    Model name:            Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
      CPU family:          6
      Model:               94
      Thread(s) per core:  2
  ....

• Check which threads share one CPU core. In the example below threads 0 and 4 share core 0, threads 1 and 5 share core 1, etc.

  $ cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list
  0,4
  1,5
  2,6
  3,7
  0,4
  1,5
  2,6
  3,7
  
  or
  
  $ lscpu --extended
  CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
    0    0      0    0 0:0:0:0          yes 4000,0000 800,0000 2100,0669
    1    0      0    1 1:1:1:0          yes 4000,0000 800,0000 2100,0020
    2    0      0    2 2:2:2:0          yes 4000,0000 800,0000 2100,0920
    3    0      0    3 3:3:3:0          yes 4000,0000 800,0000 2100,0281
    4    0      0    0 0:0:0:0          yes 4000,0000 800,0000 2099,9751
    5    0      0    1 1:1:1:0          yes 4000,0000 800,0000 2100,0039
    6    0      0    2 2:2:2:0          yes 4000,0000 800,0000 2100,0371
    7    0      0    3 3:3:3:0          yes 4000,0000 800,0000 2100,0769

  
  

• Disable threads such that there is only one active thread per core. Example:

  $ sudo bash -c 'echo 0 > /sys/devices/system/cpu/cpu4/online'
  ...
  [wer@square GettingStartedGuides]$ lscpu --extended
  CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
    0    0      0    0 0:0:0:0          yes 4000,0000 800,0000 2200,1321
    1    0      0    1 1:1:1:0          yes 4000,0000 800,0000 2200,0020
    2    0      0    2 2:2:2:0          yes 4000,0000 800,0000 2200,0300
    3    0      0    3 3:3:3:0          yes 4000,0000 800,0000 2200,5020
    4    -      -    - -                 no         -        -         -
    5    0      0    1 1:1:1:0          yes 4000,0000 800,0000 2200,0171
    6    0      0    2 2:2:2:0          yes 4000,0000 800,0000 2200,0020
    7    0      0    3 3:3:3:0          yes 4000,0000 800,0000 2200,0891

• Make configuration permanent by using a custom Linux startup script.