The AlphaVM-Pro emulator is a professional version of the AlphaVM product. It is our main commercial product. It is designed to replace wide range of Alpha systems in various environments. The product adheres to high availability and performance requirements. Here are its key features.

  • AlphaVM-Pro is designed to replace a large range of Alpha systems with various number of CPUs, memory sizes, and peripheral options.
  • AlphaVM supports the following guest operating systems: OpenVMS and Tru64/Digital Unix. Linux boots as well, but we do not support it.
  • The AlphaVM performance depends on the host system. On a fast modern system the performance is of an EV6 or EV7 class Alpha. See the benchmark page for details.
  • Normally modern servers consume less energy than Alpha systems. Therefore, using AlphaVM lowers your energy bill. However, AlphaVM goes even further in this direction. AlphaVM-Pro supports detection of the guest OS idle state. When the guest OS is idle, the emulator is able to release the host CPU for energy saving.


Supported host OSWindows Server 2012R2, 2016, 2019.
Windows 7, 8, 10,
Linux Debian 9,10,
CentOS 7
Supported host CPUIntel Xeon x64
Emulated chipsetsTsunami/Typhoon.
AlphaVM 2.0 also supports Gamma, Rawhide, Titan and Wildfire.
Maximal number of emulated Alpha CPUs4 for AlphaVM-Pro 1.5 and 1.6,
32 for AlphaVM-Pro 2.0,
The number depends on the emulated chipset and system type
Emulated CPU typeDepends on the chipset: EV4, EV5, EV6.
Maximal emulated RAM32GB
Number of emulated PCI hoses1-2 (per SBB)
Number of emulated PCI slots3-6/hose
Emulated serial line mappingssocket/virtual, serial/physical
Emulated serial line portsCOM1/tty00,COM2/tty01.
AlphaVM 1.6 has additional COM3/tty04 and COM4/tty03
Emulated SCSI controllersISP1040,
On AlphaVM 2.0 NCR53C8xx
Disk mappingscontainer files, physical devices, SCSI pass through.
CDROM mappingsISO image, physical device, SCSI pass through.
Tape mappingstape container files, SCSI pass through.
Emulated FibreChannel Not available. In most cases can be migrated to emulated SCSI.
Emulated IDENot available. In most cases can be migrated to emulated SCSI.
Emulated Floppy diskNot available.
Emulated USBNot available.
Ethernet emulationTulip NIC: 21x4x.
Ethernet transfer throughputDepends on the host NIC, usually 1000Mbps
Supported console typesOnly serial, VGA not supported.
Usually the graphics can be redirected to an X server via X Windows.
Supported OpenVMS versionsFrom 7.1-2; 6.1 for AlphaVM 2.0.
Depends on the chipset.
Supported Tru64/Digital Unix versionsFrom 4.0e; 4.0a for AlphaVM 2.0.
Depends on the chipset.

Getting started

Please register on this site. We will contact you using the registration email to further help you.

In order to assess the migration feasibility and complexity we will need some technical information about your Alpha system. Fore the details please check here.

Usually we run the migration projects as follows:

  1. The customer provides a host system to run AlphaVM evaluation. The host system must have enough resources. The system used for the evaluation does not have to be as fast as the intended production system, but the performance consequences of running on a slower system must be taken into account during the evaluation assessment.
  2. The customer provides EmuVM with remote access to this host system.
  3. EmuVM provides instructions and tools to create the disk images of the real Alpha system.
  4. The customer takes the disk images and places them on the host system using the instructions and the tools provided. Please note that EmuVM does not need to access the original system. The original system remains intact, although some downtime might be unavoidable (depending on the system configuration).
  5. EmuVM creates an AlphaVM instance on the host server:
    1. EmuVM tunes the host system.
    2. EmuVM installs AlphaVM on the host system.
    3. EmuVM provides a temporary 30 days evaluation license. EmuVM makes an AlphaVM configuration that reflects the original system. Disk images are used to create disk container files, which are virtual disks used by AlphaVM.
    4. EmuVM tunes the guest operating system (OpenVMS or Tru64) to run on new virtual “hardware”.
    5. Some additional guest OS configuration can be required: new network addresses etc.
    6. EmuVM performs some tests to see that the OS functions correctly.
  6. EmuVM lets the customer evaluate and test the resulting AlphaVM system.
  7. The customer evaluates the system. It is up to the customer to test whether the system works for them. EmuVM assists, if there are problems or questions.
  8. Based on the evaluation results the customer decides whether to purchase the system or not.
    • If the system is purchased, the customer pays EmuVM the AlphaVM license fee and the fee for performing the migration (and optionally for support).
    • If the customer decides not to purchase the system, the fees are not to be paid. With this approach, the customer does not invest much in the project before it is known to work for the customer. We are confident in our product and take the risk as low of that the product is not purchased after we invested time in the migration.

Please note that, if multiple systems are to be migrated, we migrate only one system for evaluation. The procedure will be discussed with the customer and adjusted. For complex migrations (e.g. with clustering), the procedure can be significantly different; it will be worked out with the customer.