Virtualization Solutions for
OpenVMS & Tru64 Systems

VAX and Alpha Hardware Emulation on a PC Host

HW Replacement + Server Consolidation + Business Continuity

Improve Reliability * Decrease Cost * Enhance Productivity

vtAlpha Products

vtAlpha Host System Requirements (Single Instance)

The following requirements and recommendations apply to the host system on which vtAlpha will run. A list of supported systems, virtual machine hypervisors, and devices is available in the vtServer Host Platform Compatibility List. vtServer Host Platform Compatibility List, available from the Documentation page of our web site.

Please see the section Multiple Instance Requirements below for additional requirements when multiple Alpha instances are emulated on the same host.

The vtAlpha license is stored on a USB hardware key. The USB key may be accessed directly on the host system or via the network. Network-based keys may be present in other computer systems (not necessarily running vtAlpha) or in dedicated vtLicense servers. vtLicense product information is available from the Documentation page of our web site.


The performance of the vtAlpha emulator is affected by the clock speed and technology of the host system CPU. Increasing the host CPU clock speed will increase the speed of the emulation. For a given clock speed, the latest Intel chip technology (V4, V5) runs faster than older chips. Increasing the CPU cache size may also improve performance.

A modern, fast Intel or AMD 64-bit CPU with a minimum clock speed of 3.0 GHz is recommended. Hyper-threading must be disabled on the host.

When replacing Alpha systems with clock speeds of 1 GHz or higher, a minimum clock speed of 3.2-3.4 GHz may be required. In testing we have observed significant performance improvements using HP Gen 9 and Gen 10 servers using Intel V4 chips with a large (20 MB or larger) CPU cache.

Every virtual Alpha CPU requires a full host CPU-core to run. In order to facilitate the Alpha CPU process vtAlpha needs 50% extra CPU capacity on the host for adjacent and supporting tasks. This means every virtual Alpha CPU requires 1.5 Host CPU-core, at a minimum.

For most vtAlpha implementations this will be sufficient. However, for Alphas that were exercised harder it might be necessary to assign extra host CPU-power to keep up with the high performance demand of the Alpha-based software. This can only be assessed by running the user applications. vtAlpha allows to manually assign more host CPU-resources to a certain virtual Alpha by using the "JIT Processors" parameter in the vtAlpha configuration (Advanced Options).

The default value of this parameter is 0, meaning vtAlpha will claim one additional host CPU-core for every vtAlpha instance in the product range vtAlpha-AS - vtAlpha-ES. In case of vtAlpha-GS it claims one additional host CPU-core per QBB. When manually assigned a value other than 0, vtAlpha will allocate that number of host CPUs instead. This allows to assign more than the default setting (note: in the case of vtAlpha-GS you are able to assign less than what is allocated by default).

vtAlpha-AS to vtAlpha-ES:

Alpha CPUs + 50% + additional JIT processes


Alpha CPUs + 50% + QBBs

unless the JIT Processor parameter is used, then the following formula applies:

Alpha CPUs + 50% + JIT processors

Please Note: vtAlpha runs best when installed directly on the X86 hardware (Bare Metal), but it also runs on a Virtual Machine host (VMware, Hyper-V, KVM, Xen). When running on a VM the same host requirements apply as for Bare Metal installation.

Note that by default these Virtual Machine products apply smart allocation mechanisms, allowing their guests to share the host hardware. This may make sense for general purpose environments, but not for Alpha virtualization. vtAlpha must have unshared access to the hardware of the host it is running on, otherwise it may result in performance degradation or even more severe problems. The OpenVMS and Tru64 operating systems expect the Alpha hardware they run on to be available to them in full. Any delay in availability may be assessed as a hardware malfunction by VMS/Tru64, causing the OS to crash.

It is therefore mandatory to configure the Virtual Machine host such that the virtual Alpha environment receives the resources it requires, without sharing them with other guests on the host VM.

Operating System

vtAlpha runs best directly on the Bare Metal host hardware: no host operating system is required. vtAlpha may also be run in a virtual machine providing x86-64 emulation. A list of supported hypervisors is provided in the vtAlpha Host Platform Compatibility List. vtAlpha Host Platform Compatibility List, available from the Documentation page of our web site. If the vtAlpha host is a virtual machine, it is recommended that the hypervisor be installed on Bare Metal, not running under an operating system such as Windows or Linux.


vtAlpha requires more memory than the physical Alpha hardware, but it is far less expensive than the original. Please use this formula to calculate the minimum memory required for each instance of the emulator:

Host memory = 1GB + (GB of Alpha system memory x 1.25) + (Number of disks/8 in GB)

Example: For a 4GB Alpha with 16 disks, the result would be 1 + 5 + 2 = 8GB


One dedicated physical network interface is highly recommended for host system management.


A minimum of 40 GB of host storage is recommended for installation of the vtServer software. This will provide adequate space for the software as well as configuration and log files, dumps, page and swap space, etc.

A DVD drive is recommended for loading software distributions. If no DVD drive is available, updates may be applied from a USB drive or a load image file (.ISO) can be provided. vtAlpha versions 2.5.2 and later provide the capability to upload updates using vtMonitor; a DVD drive is not required.

Disks in the virtual Alpha environment may be mapped either to physical disks mounted on the host, where the entire drive is utilized for the Alpha volume; or to logical devices, which are container files that exist within the host file system. One container file contains the entire Alpha file system for a single disk device.

NOTE: HP disk controllers with software RAID capability are not supported for use with the RAID feature enabled. Controllers with hardware RAID capability are fully supported. For details, see the vtServer Host Platform Compatibility List. vtServer Host Platform Compatibility List, available from the Documentation page of our web site.

vtAlpha version 2.4 and later provide full Fibre Channel (FC) support using virtual KGPSA adapters. A list of supported host Fibre Channel adapters is available in the vtServer Host Platform Compatibility List.

vtServer can utilize most types of disk storage supported by the host (SCSI, SAS, SATA, iSCSI, FC, NAS, SAN, or cloud). Physical disks must map to a physical drive, not a partition. Logical disks may be stored on a either partitioned or unpartitioned drives.

TapeMGR can be used to virtualize a physical tape and to use tape container files instead of physical tape cartridges. Virtual tape devices may be mapped to physical SCSI tape devices connected to the host system.

Many legacy SCSI disk and tape devices may be connected to the host system and mounted by the virtual Alpha or VAX systems. This can be useful for transferring data from the existing system and restoring archived or backup data. Due to the improved performance of modern devices and the age and potential reliability concerns of the older mechanical devices, we recommend that the older disk and tape devices only be used to transfer data to new devices or for retrieval of archived data.

Multiple Instance Requirements

Multiple instances of vtAlpha may be run on a single host system. When using the Bare Metal version of vtVAX, vtAlpha and vtVAX instances may be combined on a single host. The host hardware requirements are the sum of the requirements for each vtAlpha and vtVAX instance that will be running simultaneously.

The host CPU cores dedicated for vtAlpha I/O processing may be shared by two vtAlpha instances. For example, a one processor virtual Alpha requires 1.5 host CPU cores. A single instance of this configuration requires a 2 core CPU. When four instances are run on the same host platform only 6 cores are required (4*1.5), not 8.

vtAlpha licenses for multiple instances may be stored on a single hardware key.