Frequently Asked Questions

Helpie FAQ

  • Host

    Questions related to the system that hosts AlphaVM.

  • Which Windows versions can be used to run AlphaVM?

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

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

  • Which Linux distros can be used to host AlphaVM?

    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.

  • Shall I chose Windows or Linux as the host system?

    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.

  • Does AlphaVM run on a hyper-visor (like VMware, Hyper-V, ProxMox VE, etc).

    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.

  • Can I run multiple instances of AlphaVM on one machine?

    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.

  • Product

    Questions about the AlphaVM product and licensing.

  • What if my license dongle fails?

    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.

  • What is the difference between AlphaVM-Pro and AlphaVM-Basic?

    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.

  • CPU

    Questions about AlphaVM CPU features and configuration.

  • Why AlphaVM alsways consumes 100% of the host CPU core?

    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.

  • How fast is AlphaVM CPU?

    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 [emuvm_link id=22 title="benchmarks page"] for more information about AlphaVM performance.

  • What about synchronous vs. asynchronous JIT?

    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.

  • What does JIT mean in the CPU server name.

    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.

  • What is CPU server: basic, JIT1, JIT2, JIT3?

    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 naive 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 naive 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 [emuvm_link id=22 title="benchmark page"].

    The CPU server type does not say about 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.

  • Tru64

    Questions about Tru64/Digital UNIX.

  • Does AlphaVM emulate Tru64/Digital UNIX?

    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.

  • Is Tru64/Digital UNIX supported on AlphaVM?

    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 AlphsVM 1.x.

  • OpenVMS

    Questions about OpenVMS

  • Does AlphaVM emulate OpenVMS?

    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.

  • Is OpenVMS supported on AlphaVM?

    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.

  • Serial lines

    Serial lines

  • Can I connect the emulated serial line to a real serial line?

    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.

  • Why does my terminal print characters double?

    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

  • Can I connect a real VT100 terminal to the emulator?

    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.

  • Can I use a terminal emulator other than PuTTY?

    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.

  • Network

    Network configuration.

  • Does AlphaVM emulate 1gbit NIC?

    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.

  • Why does not network work on VMware?

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

    See [emuvm_link id=365 text="this article"] for more information.

  • Can I connect between AlphaVM guest OS and the host OS?

    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.

  • Why does AlphaVM get SIGSEGV on Linux during boot, when network is configured?

    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.

  • Disks

    Questions about disks

  • How do I create an empty disk container file?

    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.

  • How do I boot from a CD?

    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.

  • Does AlphaVM support FibreChannel storage?

    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.

  • Can I use iSCSI disks?

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

  • How do I change the CD medium in a virtual CD?

    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

  • Tapes

    Questions about tapes.

  • Why does the real tape backup fail with BACKUP-F-NOTANSI on OpenVMS?

    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.

  • What is a virtual tape?

    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.

  • Can I use a real tape drive with AlphaVM?

    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.