Frequently Asked Questions

AlphaVM by default always consumes 100% of the host CPU core, even when the guest OS (OpenVMS or Tru64) is idle. This is because the guest OS idle loop is code that does not do anything to release the CPU. AlphaVM-Pro has a feature called the idle release. AlphaVM recognizes the idle loops of the supported guest OSes and releases the CPU for a short time quantum when the idle loop is hit. This feature significantly lowers the CPU consumption of idle systems. As the result the electricity consumption is also lowered.

AlphaVM supports several CPU implementation back-ends. They all implement the same Alpha CPU functionality, but in various ways.

• Basic CPU is the simplest CPU implementation based on the interpretation of Alpha instructions fetched from the memory. This CPU serfver is the only CPU server available in AlphaVM-Basic.
• JITx CPUs are based on the Just-In-Time compilation of Alpha code to increase the performance.
  • JIT1 server compiles to byte code. Its performance is almost double of the basic CPU.
  • JIT2 server compiles Alpha code to native x86-64 code. Its performance on most workloads is about a factor of 5 faster than the basic CPU.
  • JIT3 server compiles Alpha code to native x86-64 code. This CPU server applies sophisticated optimization. It’s performance is a factor of 10 faster than the basic CPU.

AphaVM-Pro is offered with JIT3 CPU. AlphaVM-Basic only supports the basic CPU. Other CPU servers are used merely for debugging.

For the performance figures of the JIT3 see the https://emuvm.com/support/benchmarks/.

The CPU server type does not determine the emulated CPU features or type like EV4, EV5, EV6 or EV7. The CPU server type just determines the performance. The CPU features are determined by the emulated system type of the system containing the CPU. Basically, both emulated EV4 or EV6 with JIT3 will run at (approximately) the same speed.

JIT stands for Just-In-Time compilation. The JIT CPU servers on the fly compiles the Alpha code to native x86-64 code. This technology allows to significantly increase the CPU performance, because the compiled code runs much faster. JIT3 is i=on most workloads a factor of 5-10 faster than the interpreter.

By default JIT is asynchronous. It means that the CPU interprets Alpha code when there is no compiled version of it. At the same time the JIT compiler compiles the code in case it is needed next time. Synchronous JIT would compile first and then execute. There is no parallelism in it. Synchronous JIT is there merely for testing and debugging. There exist applications that constantly modify or generate code. Synchronous JIT is very inefficient with such applications, due to the compilation overhead for the code that is executed once. However, in some cases synchronous JIT is somewhat faster than asynchronous one, because it does not suffer from the synchronization overhead.

AlphaVM-Basic performs is a slow EV4 system. AlphaVM-Pro in JIT3 mode on a modern and powerful host can be as fast as EV7. Check the https://emuvm.com/support/benchmarks/ for more information about AlphaVM performance.

We have a tool that we call Make disk.

• On Windows the Tools menu container Create disk image.
• On Linux there is a tool called emuvm-mkdisk. Run it with the -h options to see the help.

Note that the tool only creates an empty disk image. Such a disk container file can be connected as a disk to AlphaVM. It has to be initialized/formatted before it can be mounted in the guest OS. Alternatively, it can be used as a target to extract a disk backup.

Currently there is no “button” to eject or load virtual CD media. However, you can eject/load the media issuing a command from OpenVMS or Tru64 (see the subsections below).

Currently you cannot specify another CD image name on the fly. However, you can put another image in the file with the same name and mount it again. The virtual medium is loaded automatically, if the file is present.

On OpenVMS.

you can use the RZT tools for it. First define the symbol:

$ rzt:==$sys$etc:rztools_alpha

Unload the CD:

$ rzt dka400 /stop

Load the CD:

rzt dka400 /start

On Tru64/Digital UNIX.

You can eject the CD as follows:

scu -f /dev/rdisk/cdrom0c eject

It is advised to use an ISO image instead of a real CD.

• On Windows you can access the real CD by a name like “\.\Cdrom0”.
• On Linux it is usually /dev/cdrom.

To boot Tru64 or OpenVMS from the CDROM.

• Add a CDROM to the configuration, set its SCSI BUS, SCSI ID and the file/device name. For the CDROM to appear as DKA400 set SCSI_BUS=0, SCSI_ID=4, SCSI_LUN=0.
• Run the VM. It will show the SRM console prompt >>>.
• In that console prompt you can type commands like show dev to see what devices are seen by the VM’s firmware.
• Determine your CDROM device name and run a boot commands like boot dka400. The system will boot from CD. The device name depends on the selected SCSI BUS and the SCSI ID of the CDROM device.

No, currently AlphaVM does not support FibreChannel.

In most cases the FibreChannel disks could be migrated to virtual SCSI disks.

On OpenVMS one can usually change the disk logical names to use DKxy instead of DGxy.

On Tru64 you can usually just set WWIDs to reflect the original disks IDs.

You can use them with AlphaVM-Pro using the SCSI-Pass-through unit.

Currently AlphaVM does not support a graphic controller (VGA). However, most graphic applications using X-Window/DECWindow can be redirected to a remote display. This display can be located on the machine that hosts AlphaVM. One would need to run an X-server on that machine. On Windows we recommend VcXsrv X-server. Linux usually has own X server, if the graphic environment is installed.

It is important to enable the X protocol connection through the firewall. In the firewall settings check that VcXsrv/Xming rule is enabled for private and public use or add own rule to enable TCP ports 6000 and 6001.

Below are examples of starting the X servers from the command line

cd \Program Files (x86)\Xming
Xming -ac -multiwindow -clipboard

vcxsrv.exe -screen 0 1280x1024 -ac +extension Composite +extension DAMAGE +extension DOUBLE-BUFFER +extension DPMS +extension GLX +extension RANDR +extension RENDER +extension SECURITY +extension X-Resource +extension XTEST +extension XFIXES

On OpenVMS the display can be set as shown by the following example command

$ set display /create/node=192.168.2.119/trans=tcpip

The graphics can be tested for instance by the following command

$ mc decw$clock

A remote session can be started manually using

$ mc decw$startlogin

On Tru64 the default display is defined by the environment variable display. In shell it can be set as in the following example.

DISPLAY=192.168.2.12:0.0
export DISPLAY

The redirection can be checked by running a simple application like xclock:

xlock

As the result a clock should appear on the screen 0 at 192.168.2.12

On Windows some anti-virus software is known to remove services that are not known to it or not signed with a certain certificate.

Starting from AlphaVM 1.5.71 and 1.6.13 all involved executables are signed with an extended validation certificate. This certificate must improve the situation with the recognition of AlphaVM as a safe product.

We recommend a server OS starting with Windows Server 2012 R2 (x64).

The workstation is supported starting from Windows 7 (x64).

We support the following Linux versions:

• CentOS 7 (x64)
• Debian 10 (x64)

We continue to support earlier versions for customers that have them and that are covered with support.

We support all these systems to give you a choice. It does not matter much what you chose, because when you work with the emulated Alpha, it hardly makes a difference what OS is hosting the emulator. We advise to chose the OS you have more confidence with.

There is one difference to consider. The Windows version currently has a graphic user interface, whereas Linux and FreeBSD versions do not have it. On Linux and FreeBSD the AlphaVM can be launched only from the command line. On Windows the Launcher GUI manages the configuration and the startup of the emulator in a convenient way.

Yes, AlphaVM is supported on several hyper-visors.

Supported Hyper-Visors.

• VMware ESXi 5.5 and later
• Hyper-V 2012R2 or later
• ProxMox 4 and later.

VirtualBox

AlphaVM has also been reported to run on VirtualBox, but we do not support it. Older versions of VirtualBox incorrectly passes the host CPU capability flags. AlphaVM will not run with the flags passed by default. The flags can be corrected by the following command run from the Windows command prompt:

"C:\Program Files\Oracle\VirtualBox\VBoxManage" setextradata AlphaVM VBoxInternal/CPUM/CMPXCHG16B 1

Here AlphaVM is the name of the virtual appliance to be changed.

Performance Remarks

AlphaVM is a sort of a hyper-visor itself. When running on a hyper-visor one gets double virtualization, which has some consequences.

AlphaVM expects to use all the necessary resources provided by the hardware. In particular AlphaVM CPU expects to get a 100% of the host CPU. AlphaVM CPU is a single threaded workload with respect to the host CPU. Due to the hosting hyper-visor scheduling it can happen that AlphaVM does not get 100% of the host CPU, which will result in severe performance degradation.

It is similar with memory. If the hyper-visor swaps out AlphaVM memory, it causes severe performance degradation.

It is not recommended to run AlphaVM on a hyper-visor with over-committed resources.

AlphaVM SMP configurations suffer from the lack of resources even more than single CPU configurations. Each AlphaVM CPU runs in its own thread. Due to the hyper-visor scheduling these threads can get different host CPU resources, which can result in the CPU synchronization problems in the guest OS. In the worst case scenario on OpenVMS one can get an SMP timer watchdog errors: OpenVMS can think that a CPU hangs if it does not respond within a given timeout.

Conclusions

AlphaVM is supported on several hyper-visors. However, we do not recommend to run on hyper-visor if

• The performance is important.
• The realtime response is important.
• It is SMP on over-committed hyper-visor.

We recommend that the hyper-visor VM hosting AlphaVM is configured with hardware resources fully available to it, in such a way that the preemption of AlphaVM is unlikely.

Yes, you can. You have to set separate configurations in separate directories for all your instances.  You have to make sure the following settings of the VMs that will run simultaneously do not conflict (are different)

• The serial port numbers of the mapped the COM1 and COM2
• If the CPU affinities are used, they must not conflict.
• The disks must not be shared, if it is not intended.
• The licenses must be different.
• The log files must be different. They will be different by default, if the configurations are, as advised, in different directories.

On VMware often the network infrastructure puts some restrictions on packets that are passed through NICs and switches.

See this article for more information.

It is likely that AlphaVM has no permission to access your pcap functionality (raw ethernet). You should either enable AlphaVM capabilities to access pcap from the user mode or run AlphaVM as root.

AlphaVM currently emulates 100 and 10 mbit NICs. However, it does not limit the network throughput, because the emulated NIC actually operates at the speed of the underlying host NIC, no matter what the speed of the emulated hardware is. On a 1gbit NIC the actual speed will be 1gbit. Only the nominal speed will be slower.

Please note that, if you use AlphaVM-Basic, your bottleneck will be the slow CPU. It will limit your actual speed.

Yes, you can use NPCAP in WinPCAP compatible mode. NPCAP can be installed in WinPCAP compatible mode. The NPCAP installer has a checkbox to select this mode.

Yes, you can. The simplest way is to use a dedicated NIC for AlphaVM.

Alternatively, on Linux it is possible to use a tap NIC for AlphaVM and bridge it with the real NIC.

Yes, AlphaVM is designed to run OpenVMS as the guest system. AlphaVM supportes OpenVMS starting from 6.1 on AlphaVM 2.x and 7.1-2 on AlphaVM 1.x.

On OpenVMS the display can be set as shown by the following example command

$ set display /create/node=192.168.2.119/trans=tcpip

The graphics can be tested for instance by the following command

$ mc decw$clock

A remote session can be started manually using

$ mc decw$startlogin

On OpenVMS the display can be set as shown by the following example command

$ set display /create/node=192.168.2.119/trans=tcpip

The graphics can be tested for instance by the following command

$ mc decw$clock

A remote session can be started manually using

$ mc decw$startlogin

No, AlphaVM does not emulate OpenVMS. AlphaVM emulates Alpha hardware and can run OpenVMS/Alpha as the guest system.

AlphaVM emulates the whole Alpha system with the CPU, memory, chipset, SCSI controllers disks, etc. OpenVMS runs on the AlphaVM virtual machine as on a real Alpha machine.

AlphaVM can be used to replace a real Alpha system. The applications software will run on AlphaVM unchanged. OpenVMS may need some reconfiguration to run on new virtual hardware.

The main differences are as follows.

• AlphaVM-Basic is designed for hobbyists whereas AlphaVM-Pro is designed for commercial customers.
• AlphaVM-Pro has an option for annual support & maintenance.
• We do not assist migrations to AlphaVM-Basic.
• AlphaVM-Basic has annual license. AlphaVM-Pro has perpetual license.
• AlphaVM-Basic licensing works by connection to our license server. AlphaVM-Pro supports licensing by USB dongle or by binding to the VMware appliance.
• AlphaVM-Basic is limited to a single basic CPU. AlphaVM-Pro supports SMP, up to 4 CPUs in AlphaVM 1.x and 32 CPUs in 2.x.
• AlphaVM-Basic CPU speed is limited. AlphaVM-Pro has much faster CPU. The Pro CPU on most workloads is a factor of 5 to 10 faster.
• AlphaVM-Basic is limited to 1024MB RAM. AlphaVM-Pro has no limit in the license.
• AlphaVM-Pro supports the idle loop release. It is able to release the host CPU when the guest OS is idle.
• AlphaVM-Pro supports SCSI Pass Through, which can be used to access physical tapes, SCSI disks, iSCSI disks and other SCSI devices.
• AlphaVM-Pro supports physical serial lines.

We offer a disaster recovery dongle that has cumulative run time limit of 30 days. This dongle can be used to bridge the main license dongle outage. In the 30 days the broken dongle should be sent back to us and we send the replacement dongle. The disaster recovery dongle can be then remotely reprogrammed back to 30 days.

If you are using PuTTY, please make sure you use the right configuration settings:

• Connection type is RAW
• LOCAL ECHO is FORCED OFF
• LOCAL LINE EDITING is FORCED OFF

Yes, you can configure AlphaVM to use any terminal emulator the configuration property sheets for serial ports. By default PuTTY is configured.

Please note that a terminal emulator can only be launched by the Windows GUI Launcher (EmuLaunch). The VM itself ignores the launching settings.

Please also note that AlphaVM serial lines are raw in the sense that there is no protocol over TCPIP that is operating on these lines (like TELNET). This is why PuTTY is configured in raw mode. It is incorrect to use a TELNET client with the console. You can still use your TELNET client to connect to AlphaVM via network.

Yes, emulated serial lines can be mapped to real serial lines in AlphaVM-Pro. Choose the serial server instead of the socket server. Specify the host serial device to be used.

Yes, in AlphaVM-Pro you can map the emulated serial lines to the physical serial lines of your host system. The terminal can be connected to the host serial port.

It seems that there is a problem with the host SCSI Controller LSI Ultra320. Please use another controller for SCSI Pass Through. It was successfully tested with LSI 53C8xx and with Adaptec SCSI controllers.

Virtual tape is a an emulated tape drive which stores data in a file. Such a file is called a virtual tape image. The tape image format is compatible with the SIMH VAX emulator.

Yes, you can use it with AlphaVM-Pro. Using a SCSI-Pass-through unit you can connect a tape as well any SCSI device.

To connect a SCSI tape to your host system you will need a compatible SCSI controller in your host system. Please note that RAID SCSI controllers cause problems with tape.

Yes, AlphaVM is designed to run Tru64/Digital UNIX as the guest system.

AlphaVM supports Tru64/Digital UNIX starting from 4.0a on AlphaVM 2.x and 4.0e on AlphaVM 1.x.

On Tru64 the default display is defined by the environment variable display. In shell it can be set as in the following example.

DISPLAY=192.168.2.12:0.0
export DISPLAY

The redirection can be checked by running a simple application like xclock:

xlock

As the result a clock should appear on the screen 0 at 192.168.2.12

No, AlphaVM does not emulate Tru64/Digital UNIX. AlphaVM emulates Alpha hardware and can run Tru64/Digital UNIX as the guest system.

AlphaVM emulates the whole Alpha system with the CPU, memory, chipset, SCSI controllers disks, etc. OpenVMS runs on the AlphaVM virtual machine as on a real Alpha machine.

AlphaVM can be used to replace a real Alpha system. The applications software will run on AlphaVM unchanged. Tru64 may need some reconfiguration to run on new virtual hardware.