VSI OpenVMS x86-64 V9.2-3

VSI OpenVMS x86-64 V9.2-3 does not support cluster common system disks.

VSI OpenVMS x86-64 supports SATA disks across all supported hypervisors.

On Oracle VirtualBox, VSI OpenVMS also supports virtio-scsi disks.

On VMware ESXi, VSI OpenVMS also supports the configuration of up to four LSI Logic Parallel SCSI controllers per virtual machine. Note that the LSI Logic SAS controllers are not supported.

Starting with the V9.2-3 release, VSI OpenVMS x86-64 supports the VMware VMDirectPath I/O feature with the HPE SN1100Q fibre channel HBAs for data disks. For more details, refer to Section 3.1.17, “VMware VMDirectPath I/O Support for Data Disks”

On KVM/QEMU, VSI OpenVMS also supports SCSI disks on a virtio controller. Note that only one virtio-scsi adapter can be configured and used on a VSI OpenVMS x86-64 V9.2-x system. This functionality requires QEMU version 6.2 or later.

VSI OpenVMS x86-64 V9.2-3 can be installed as a guest operating system on KVM, VMware, and VirtualBox virtual machines using the X860923OE.ISO file.

KVM

For KVM, VSI recommends ensuring that your system is up-to-date with KVM kernel modules and the associated packages necessary for your particular Linux distribution.

VSI has tested VSI OpenVMS x86-64 V9.2-3 with KVM on several Linux distributions. The following table includes the Linux distribution and version, as well as the QEMU version:

VMware

VSI has tested VSI OpenVMS x86-64 V9.2-3 with the following VMware products:

VMware Licenses

Starting with VSI OpenVMS x86-64 V9.2-3, all VMware license types are supported if you are connecting to your virtual machine using the Guest Console feature (see Section 3.1.5, “Guest Console”).

Note, however, that only the VMware vSphere Enterprise or Enterprise Plus license types support virtual serial port connections on VSI OpenVMS x86-64 V9.2-3.

VirtualBox

VSI tests with VirtualBox 7.x and regularly installs patches when they are available.

VSI recommends that you verify the MD5 checksum of the X860923OE.ZIP file after it has been downloaded from the VMS Software Service Platform to your target system. The MD5 checksum of X860923OE.ZIP must correspond to the following value:

AF20430EE7763ED65BD42231D27F8A76

To calculate the MD5 checksum, you can use any platform-specific utilities or tools that are available for your system.

VSI OpenVMS x86-64 requires that the CPU supports certain features that are not present in all x86-64 processors. When using virtual machines, both the host system and guest virtual machine must have the required features.

Host System Check

Before downloading the VSI OpenVMS x86-64 V9.2-3 installation kit, VSI recommends that you determine whether your host system has the required CPU features to run VSI OpenVMS x86-64. For this purpose, execute a Python script called vmscheck.py on your host system. This script, along with the accompanying PDF document entitled VMS CPUID Feature Check, can be downloaded from the official VSI OpenVMS x86-64 web page.

The VMS CPUID Feature Check document contains instructions on how to run the script and interpret the results. It also describes script limitations.

Guest Virtual Machine Check

The OpenVMS Boot Manager performs the CPU feature check on the guest virtual machine. The CPU feature check is performed automatically every time the Boot Manager is launched. If the check has passed successfully, the following message is displayed:

Checking Required Processor Features:     PASSED

In addition, before booting VSI OpenVMS x86-64 V9.2-3, you can issue the following Boot Manager command to list the compatibility details:

BOOTMGR> DEVICE CPU

During the installation, you will be prompted to register Product Authorization Keys (PAKs) for the base operating environment and any layered products that are not included in the base OS.

For more information about licensing, refer to the relevant section in the VSI OpenVMS x86-64 V9.2-3 Installation Guide.

VSI OpenVMS x86-64 V9.2 and later provides support for the following network stacks:

VSI TCP/IP Services V6.0-26 is part of the VSI OpenVMS x86-64 V9.2-3 installation and will be installed along with the operating system. For more information, refer to VSI TCP/IP Services V6.0 Release Notes and other VSI TCP/IP Services documentation available at docs.vmssoftware.com.

During the VSI OpenVMS x86-64 V9.2-3 installation, you will also be offered the option to install either VSI DECnet Phase IV or VSI DECnet-Plus.

$ @SYS$UPDATE:SYS$MD.COM

$ PURGE SYS$LOADABLE_IMAGES:SYS$MD.DSK

This section lists features introduced in the current release.

$ SYS$MANAGER:SYS$LOGIN_SWITCH.COM

%%%%%%%%%%% OPCOM 25-OCT-2024 12:33:46.60 %%%%%%%%%%%
Message from user AUDIT$SERVER on OM2701
Security alarm (SECURITY) and security audit (SECURITY) on OM2701, system id: 1789
Auditable event: Network login failure
Event time: 25-OCT-2024 12:33:46.60
PID: 00000457
Process name: EVL
Username: DECNET
Image name: OM2701$DKC100:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Status: %ACME-E-TIMEOUT, requested operation has timed out

$ PURGE SYS$COMMON_MD:[SYSEXE] LOGINOUT.EXE

$ WRITE SYS$OUTPUT F$CVTIME("0001:001:00", "DELTA", "DATETIME")
0 0001:001:00.00

$ WRITE SYS$OUTPUT F$CVTIME("0001:001:00", "DELTA", "DATETIME")
0 01:01:00.00

$ RUN /DELAY="0 00:00:01" TEST.EXE

$ RUN /DELAY="1 00:00:1" SELECT.EXE
%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
\0 100:00:\

$ RUN /DELAY="0-00:00:01" TEST.EXE

BOOTMGR> OPA0

virsh attach-interface --model virtio-net-pci-non-transitional ... 
virsh attach-interface --model virtio-net-pci-transitional ...

This section lists issues that have been fixed with the current release.

%GCTERM-E-MEMALOC Bad Canvas

Error: last state machine operation was not end_sequence

$ INSTALL CREATE DKA200:[DATA]TEST.DAT
%INSTALL-E-FAIL, failed to CREATE entry for DISK$USER:<DATA>TEST.DAT
-IMGACT-F-NOTNATIVE, image is not an OpenVMS Alpha image
$

$ INSTALL CREATE DKA200:[DATA]TEST.DAT /NOOPEN

CMPB R2,#<<sym>/2>

The following functionalities, products, and commands are not available in VSI OpenVMS x86-64 V9.2-3:

A BACKUP command of the form:

$ BACKUP/INITIALIZE input-disk:[directories...]*.*; output-disk:save-set.bck/SAVE

where the output volume is a disk that has been mounted /FOREIGN, does not work in VSI OpenVMS x86-64 V9.2-3 and may yield the following error:

%BACKUP-F-OPENOUT, error opening DKA200:[000000]DKA200$504.BCK; as output
-SYSTEM-W-BADIRECTORY, bad directory file format

This type of operation was originally developed to allow the backup of a large non-removable disk onto a series of smaller removable disks. The feature, referred to as "sequential disk" operation, is described in the VSI OpenVMS System Manager's Manual, Volume 1: Essentials.

As a workaround, initialize and mount an output volume of a size sufficient to hold the entire backup save set before issuing the BACKUP command as in the following example:

$ INITIALIZE output-disk: label
$ MOUNT output-disk: label
$ CREATE/DIRECTORY output_disk:[]
$ BACKUP input-disk:[directories...]*.*; output-disk:save-set.bck/SAVE

If a sufficiently large output disk is not available, you can instead create and mount a volume set using multiple disks with the INITIALIZE and MOUNT/BIND commands.

In a mixed-version cluster where at least one node is running VSI OpenVMS x86-64 V9.2, certain conditions might trigger a crash of all x86-64 systems, regardless of which OpenVMS version they run. This can happen when a V9.2 MSCP node that is serving disks to other cluster members gets rebooted. In this case, other x86-64 cluster members will see the disks served by MSCP go into mount verification. Upon the verification completion, the MSCP client node might crash.

The fix for this problem is to upgrade all x86-64 cluster nodes to VSI OpenVMS x86-64 V9.2-1 or later.

In VSI OpenVMS x86-64 V9.2-3, a container file can only be connected as a shared LD device accessible to multiple architectures as follows:

DECnet Phase IV will not work over a Wi-Fi connection. To be able to use DECnet Phase IV on an x86-64 virtual machine and communicate with other systems, you must have the host machine connected via an Ethernet cable.

DECnet-Plus will work over a Wi-Fi connection, but it must be tunnelled through TCP/IP.

Most operations with the ENCRYPT utility return the following error:

%ENCRYPT-F-ILLALGSEL, algorithm selection unknown, unavailable, or unsupported

This issue will be addressed in a future release of VSI OpenVMS x86-64.

VSI recommends that any privileged images linked using the LINK/SYSEXE command in VSI OpenVMS V9.2 or earlier be relinked for the current release because data structures and interfaces are subject to change between releases.

Note that the images linked using LINK/SYSEXE in VSI OpenVMS V9.2-1 do not need to be relinked for the current release.

When you run a VSI OpenVMS x86-64 image on VSI OpenVMS for Integrity Servers, no message from the image activator appears, but an access violation occurs.

This issue will be corrected in a future patch kit for VSI OpenVMS for Integrity Servers.

If the FTP service does not work after it has been started, switch to passive mode with the following command:

FTP> SET PASSIVE ON
Passive is ON

In passive mode, the FTP client always initiates a data connection. This is useful in virtual machine environments when there is network address translation (NAT) in your network.

To run this command automatically when you invoke FTP, put it into SYS$LOGIN:FTPINIT.INI. For the full description of the SET PASSIVE command, refer to the VSI TCP/IP Services for OpenVMS User’s Guide.

VSI OpenVMS x86-64 supports a maximum of 32 CPUs.

VSI OpenVMS x86-64 has extended file caching (XFC) enabled by default.

The high-performance sort/merge utility (HYPERSORT) is available in VSI OpenVMS x86-64. Enable the utility with the following command:

$ DEFINE SORTSHR SYS$LIBRARY:HYPERSORT.EXE

VSI OpenVMS x86-64 uses a boot method called Memory Disk that simplifies the boot process by eliminating boot complexity and decoupling the VSI OpenVMS Boot Manager from a specific device or version of VSI OpenVMS x86-64. Memory Disk is created and deployed automatically during the installation process.

The Memory Disk contains all files that are required to boot the minimum OpenVMS kernel and all files needed to write system crash dumps. Changes such as file modifications or PCSI kit/patch installations require the operating system to execute a procedure to update the Memory Disk container, thus assuring that the next boot will use the new images. A command procedure, SYS$MD.COM, keeps the Memory Disk up-to-date.

If you change anything that affects the boot path or dumping, you must run the command procedure SYS$MD.COM before rebooting. For instance, if you change any files referenced or loaded during booting (up to and including the activation of STARTUP), or any files used by the dump kernel, then you must run SYS$MD.COM.

However, in VSI OpenVMS x86-64 V9.2 and later there are two exceptions to the above statement. If you make any of the following changes that affect the boot path or dumping, you do not need to run SYS$MD.COM:

Use the following command exactly as specified here:

$ @SYS$UPDATE:SYS$MD

No parameters are needed, the defaults should apply.

When SYS$MD.COM completes, you must reboot.

When SYS$MD.COM is invoked, the system will display something like the following:

$ @SYS$UPDATE:SYS$MD
        Created memory disk DKE100:[VMS$COMMON.SYS$LDR]SYS$MD.DSK;1
        - using 184064 blocks in 1 extent with 1010 spare blocks
        - mounted on LDM9323: with volume label MD230120DD6A
        - contains OpenVMS V9.2-3

$

After the next system reboot, purge the memory disk with the following command:

$ PURGE SYS$LOADABLE_IMAGES:SYS$MD.DSK

VSI OpenVMS x86-64 does not support swap files. The system’s physical memory should be managed with appropriately sized system memory and page file(s).

The AUTOGEN and SWAPFILES procedures no longer create swap files on the system disk. If a swap file resides on the system disk, it will no longer be installed as part of the system startup.

In the current release, the SYSGEN INSTALL command does not support the /SWAPFILE qualifier. The use of the qualifier will result in a syntax error.

Processes may be seen in the Computable Outswapped (COMO) state. This is a transient state for newly created processes. Processes will never appear in the Local Event Flag Wait Outswapped (LEFO) or Hibernate Outswapped (HIBO) states. All performance counters associated with swapping are still present in the system. Various MONITOR displays will show swapping metrics.

VSI OpenVMS x86-64 provides support for process dumps. The only method currently available for analyzing process dumps is using the System Dump Analyzer (SDA). Most SDA commands that display data about a process can be used to examine the state of the process. For example, SHOW PROCESS, SHOW CRASH, SHOW EXCEPTION, SHOW CALL, EXAMINE, and MAP. Support for the Symbolic Debugger interface will be added in a future release of VSI OpenVMS x86-64.

VSI OpenVMS x86-64 system crash dumps are written using a minimal VMS environment called the Dump Kernel. All files used by the Dump Kernel are included in the Memory Disk described in Section 5.4, “Memory Disks”.

Interleaved Dumps

Starting with the V9.2-1 release, VSI OpenVMS x86-64 supports two system crash dump types: Compressed Selective Dump and Interleaved Dump.

A Compressed Selective Dump is written using only the primary CPU running in the Dump Kernel, while an Interleaved Dump makes use of the available secondary CPUs. If the dump device is a Solid State Disk (SSD), the dump can be written much faster, thus allowing the system to be rebooted sooner.

The DUMPSTYLE parameter specifies which dump type is being used. The default value for the parameter is 9 (Compressed Selective Dump). However, if the system has more than one CPU and the SYS$SYSTEM:MODPARAMS.DAT file does not include a value for the DUMPSTYLE parameter, then, when AUTOGEN runs, it will set the value of DUMPSTYLE to 128 (Interleaved Dump).

In OpenVMS x86-64, the only other pertinent bits in the DUMPSTYLE parameter are bit 1 (full console output: registers, stack, and system image layout) and bit 5 (only dump system memory, key processes, and key global pages). Either or both of these bits can be set in addition to the two base values (9 and 128). Bit 2 (dump off system disk) is no longer required.

Dump Off System Disk

Crash dumps can be written to the system disk or to an alternate disk which is specifically designated for this purpose.

Dumps to the system disk are written to SYS$SYSDEVICE:[SYSn.SYSEXE]SYSDUMP.DMP which can be created or extended using the SYSGEN utility.

Dumps to an alternate device can be set up as described in the example below:

You can view the setting by using the SHOW DUMP_OPTIONS command. The change is effective immediately, a reboot is not required.

Changes in SET DUMP_OPTIONS

A new qualifier, /MAXIMUM=CPUS=n, has been added to the SET DUMP_OPTIONS command. This qualifier sets the number of CPUs used by the Dump Kernel when writing an Interleaved Dump. It has no effect when a Compressed Selective Dump is used. By default, the Dump Kernel will use all eligible secondary CPUs that are available in the system, up to a maximum of 10 (including the primary CPU). Eligible CPUs are those that were halted successfully when the system crashed and that did not trigger the crash with a MACHINECHK or KRNLSTAKNV Bugcheck.

The maximum number of CPUs that can be specified in the command is also 10.

System Dump Analysis

VSI strongly recommends that the version of SDA.EXE and SDA$SHARE.EXE used to analyze a system dump be exactly the same as the version of OpenVMS that was in use when the system crash occurred. However, it is often possible to use SDA images from a different version of OpenVMS, provided there are no major differences between the versions and the warning messages by SDA are ignored (either %SDA-W-LINKTIMEMISM, or %SDA-W-SDALINKMISM, or both).

New SDA command qualifiers in OpenVMS x86-64

The SDA commands below now have new qualifiers that are specific to OpenVMS x86-64. Also, the format of several output messages has been changed to accommodate the architectural differences.

SHOW DUMP command

The qualifier /PERFORMANCE has been added to display the performance data collected by the Dump Kernel while writing a dump.

Depending on the additional keywords used, the data displayed by the SHOW DUMP/PERFORMANCE command can include system information (/PERFORMANCE=SYSTEM), per-CPU information (/PERFORMANCE=CPU), and per-process information (/PERFORMANCE=PROCESS). If no additional keywords are specified with the command, all information mentioned above will be displayed.

SHOW EXECUTIVE command

The qualifier /SDA_EXTENSION has been added to limit the list of displayed executive images to those that are paired with SDA extensions. For example, SWIS$DEBUG.EXE.

SHOW PAGE_TABLE and SHOW PROCESS /PAGE_TABLE commands

The qualifiers /BPTE, /PDE, /PDPTE, /PML4E, and /PML5E have been added to allow you to display a specific level of page table entries. The default behavior is to display the base page table entry (BPTE).

The qualifier /MODE has been added to display the page tables for a specific mode. The default behavior is to display the page tables for all modes. Valid keywords are: KERNEL, EXECUTIVE, SUPERVISOR, and USER.

SHOW POOL command

The output for the qualifier /RING_BUFFER is now affected by the additional qualifiers /ALL and /S2_NPP. The default behavior for SHOW POOL /RING_BUFFER is to display all entries in the Nonpaged Pool ring buffer. If /S2_NPP is specified, then the ring buffer for S2 pool is displayed. If /ALL is specified, then the contents of both ring buffers are displayed, interleaved by their timestamps.

The qualifier /S2_NPP, when used without /RING_BUFFER, displays only the S2 pool. The default behavior is to display all pool types.

The qualifier /USB displays only the nonpaged pool that is reserved for use by USB devices. The default behavior is to display all pool types.

VALIDATE POOL command

The qualifier /S2_NPP allows validation of only the S2 pool. The default behavior is to validate all pool types.

The qualifier /USB allows validation of only the nonpaged pool that is reserved for use by USB devices. The default behavior is to validate all pool types.

SDA commands and qualifiers not available in VSI OpenVMS x86-64

The following commands and qualifiers are not applicable to VSI OpenVMS x86-64 systems:

Other SDA command changes

The COPY command qualifiers /COMPRESS, /DECOMPRESS, and /PARTIAL cannot be used with an Interleaved Dump.

Starting with VSI OpenVMS x86-64, the call stack can be viewed in the Pthread debugger. To show the call stack, use the -o C option in the THREADS command. For example, if the debugger runs in the PTHREAD SDA extension, the command to show the call stack for thread id 3 is the following:

SDA> PTHREAD THREADS -o "C" 3
Process name: SECURITY_SERVER   Extended PID: 0000008F  Thread data:
"threads -o "C" 3"
-----------------------------------------------------------------------------
thread 3 (blocked, timed-cond) "Process_Proxy_Task", created by pthread
  Stack trace:
     0xffff83000c83b1a5 (pc 0xffff83000c83b1a5, sp 0x00000000024e3228)
     0xffff83000c87b53a (pc 0xffff83000c87b53a, sp 0x00000000024e3230)
     0xffff83000c858493 (pc 0xffff83000c858493, sp 0x00000000024e32e0)
     0xffff83000c852b04 (pc 0xffff83000c852b04, sp 0x00000000024e33f0)
     0xffff83000c8499a3 (pc 0xffff83000c8499a3, sp 0x00000000024e34d0)
     0xffff83000c844e9a (pc 0xffff83000c844e9a, sp 0x00000000024e3800)
     0x0000000080004ad8 (pc 0x0000000080004ad8, sp 0x00000000024e3900)
     0x0000000080007fe6 (pc 0x0000000080007fe6, sp 0x00000000024e3950)
     0xffff83000c8887df (pc 0xffff83000c8887df, sp 0x00000000024e3bd0)
     0xffff83000c83b0ea (pc 0xffff83000c83b0ea, sp 0x00000000024e3f00)

However, the output of the THREADS -o u Pthread debugger command that shows an SDA SHOW CALL command cannot yet be used in SDA.

SDA> PTHREAD THREADS -o u 3
Process name: SECURITY_SERVER   Extended PID: 0000008F  Thread data:
"threads -o u 3"
------------------------------------------------------------------------
thread 3 (blocked, timed-cond) "Process_Proxy_Task", created by pthread
  Unwind seed for SDA SHOW CALL 00000000024e2e40
SDA> SHOW CALL 00000000024e2e40
00000000.024E2E40 is no valid handle for a call stack start of
00000000.00000000

VSI OpenVMS x86-64 includes an initial implementation of the Symbolic Debugger. While many features work, there are some that do not work. These are listed in the following sections. VSI will address these issues in a future release.

break at DANCE\pause_actions\%LINE 138517
%DEBUG-I-NOTORIGSRC, original version of source file not found
       file used is SYS$SYSDEVICE:[DEBUG.BLUEY]DANCE.C;1
%DEBUG-W-UNAREASRC, unable to read source file SYS$SYSDEVICE:[DEBUG.BLUEY]DANCE.C;1
-RMS-E-EOF, end of file detected

User-written x86-Assembler code must follow the VSI OpenVMS calling standard (see the VSI OpenVMS Calling Standard manual) to provide exception handling information that is used by the exception handling mechanism to find a handler in one of the callers of the Assembler module. Without that information, exception handling can only call the last chance handler, which means the application will likely not be able to handle the exception.

See the following example of a user-written x86-Assembler module:

        .vms_module "MYTEST","X-01"
        .text
        .globl  MYTESTRTN
        .align 16
        .type   MYTESTRTN,@function

MYTESTRTN:
        .cfi_startproc
        pushq   %rbp                    // Establish a frame pointer
        .cfi_def_cfa_offset 16          // Record distance to saved PC
        .cfi_offset %rbp, -16
        movq    %rsp,%rbp
        .cfi_def_cfa_register %rbp

        // function body

        movq    %rbp,%rsp               // Restore stack and return
        popq    %rbp
        .cfi_def_cfa %rsp, 8            // Adjust distance to saved PC
        retq
        .size MYTESTRTN, .-MYTESTRTN
        .cfi_endproc

SYS$UPDATE:STABACKIT.COM has been been deprecated in VSI OpenVMS x86-64. The STABACKIT functionality originally supported Standalone Backup for VAX systems and has long been replaced by SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM for OpenVMS Alpha and SYS$SYSTEM:I64VMS$PCSI_INSTALL_MIN.COM for OpenVMS Integrity systems. The referenced command procedures produce a minimal installation of OpenVMS on a target device which may be booted to allow a full backup of the system disk. STABACKIT would offer to run the appropriate procedure for you.

VSI OpenVMS x86-64 V9.2-3 currently does not support minimal installation of the operating system on a non-system disk. Backup options for virtual machines include the ability to perform backup from the host operating system and the ability to checkpoint or clone within the hypervisor. One may also boot from the installation media and choose the DCL subprocess menu entry to perform a backup of the system device.

Even if the hypervisor appears to allow it, do not change the configuration of a VSI OpenVMS virtual machine while it is running, as this may cause it to hang. Before editing the settings, make sure to power off the virtual machine.

$ @SYS$MANAGER:UTC$SET_TIME.COM

This issue will be addressed in a future release of VSI OpenVMS x86-64.

On KVM/QEMU systems, when a virtual machine is powered on, the system time is set based on the value of the CLOCK OFFSET parameter in the configuration file of that virtual machine. The default value is 'utc'. Depending on the physical location of the host system, this might lead to differences between system times of the VM and the host.

To resolve this problem, use the virsh edit command to edit the XML configuration file of your virtual machine and change the value of the CLOCK OFFSET parameter to 'localtime', like so:

<clock offset='localtime'>

For more information, see the official documentation for your Linux distribution.

Host systems running Windows 10 and 11 that have previously run Microsoft Hyper-V hypervisor may fail the CPU feature checks. The issue is that certain CPU features are supported on the host system (the vmscheck.py script passes), but not on the guest system (the OpenVMS Boot Manager check fails). Primarily, the XSAVE instruction may not be present on the guest system.

This issue persists even if the Hyper-V feature has been removed. This happens because certain Hyper-V services interfere with VirtualBox.

The VirtualBox developers are aware of this issue and are working to improve the interoperability with Hyper-V.

To explicitly disable execution of the Hyper-V services that interfere with VirtualBox, perform the following steps on your Windows host system:

The XSAVE instruction should now be available to your VirtualBox guest.

Windows 11 users must additionally disable the Core Isolation feature by performing the following steps:

Note that some users have also needed to disable Hyper-V functions to resolve this issue. This can be done as follows:

Be aware that the steps described above may not be sufficient for some systems. Various resources can be found online to help users who continue to face issues. Users are also advised to contact their system administrator for help.

For more information about the CPU feature checks, see Section 2.4, “CPU Compatibility Checks for Virtual Machines” in the Section 2, “Read These Before You Start” section.

Tips on How To Determine If Hyper-V Services Impact Your VirtualBox VM

When you launch a VirtualBox guest, look for the icon in the guest window status bar.

View the log file VBox.log.

When running VSI OpenVMS x86-64 as a guest in a VirtualBox VM, TCP console ports may become unusable after a guest session has been terminated. After that, you cannot connect to your VirtualBox VM again. These ports remain in the LISTEN state even after you have disconnected the remote terminal session.

As a workaround, use the following commands to free your TCP ports and connect to your VirtualBox VM:

vboxmanage controlvm <vmname> changeuartmode1 disconnected
vboxmanage controlvm <vmname> changeuartmode1 tcpserver <port>

The VirtualBox developers have indicated that the fix will be provided in an upcoming VirtualBox maintenance release.

It has been reported that a VMware guest does not boot when a second SATA controller is added to the configuration. In their case, removing the second SATA controller eliminates the issue.

VSI has not observed boot issues when adding a second SATA controller during testing. If you encounter this situation, please report your issue to VSI support.

If you are running a VMware virtual machine with multiple buses, you may run into a problem with the list of bootable devices displayed by the Boot Manager.

If, after entering the DEVICE command, your Boot Manager display normally looks similar to the following:

but occasionally, upon shutting down your VMware virtual machine, it appears as shown below:

This means, not all of your devices and/or buses have been configured properly. Proceeding to boot your VMware virtual machine from this truncated configuration display may result in an incomplete configuration of your Virtual Machine’s buses and the disk devices on those buses.

This happens because, by default, VMware products do not allow the UEFI Shell to be launched by the platform firmware Boot Option and have the Quick Boot option enabled.

These problems can be resolved by setting the correct values for the efi.shell.activeByDefault and efi.quickBoot.enabled parameters. To do so, follow the procedure described in Section 6.8, “Possible Issues with VMware Virtual Machines”.

Virtual machines created in VMware hypervisors (ESXi, Workstation Pro, Player, Fusion) may not operate as intended until you manually set the parameters listed in the table below.

Depending on your specific configuration, there may be cases where you may not need to set one or more of these parameters. VSI provides this information in case you experience the issues these parameters address.

To set these parameters for a VMware ESXi virtual machine, follow these steps:

To set these parameters for a virtual machine running under any other VMware product, follow these steps:

On KVM/QEMU, only one virtio-scsi adapter can be configured and used on a VSI OpenVMS x86-64 V9.2-x system. Note that this functionality requires QEMU version 6.2 or later.

VSI OpenVMS x86-64 supports VirtualBox, KVM, and VMware virtual machines in OpenVMS clusters. Virtual disks can be shared in a cluster via MSCP. Starting with the V9.2-3 release, VSI OpenVMS x86-64 supports direct (non-MSCP) shared disk access via the VMware VMDirectPath I/O feature (see Section 3.1.17, “VMware VMDirectPath I/O Support for Data Disks”). Cluster common system disks are not supported.

VSI OpenVMS x86-64 was tested in a clustered configuration using V8.4-1H1, V8.4-2, V8.4-2L1, V8.4-2L2, and V8.4-2L3. VSI has tested 2-node and 3-node clusters with MSCP-served disks where appropriate, CLUSTER_CONFIG_LAN.COM, and many relevant SET, SHOW, and SYSMAN commands. Other configurations will be tested at a later date.

Adding a Node Using a Copy of an Existing System Disk

On VSI OpenVMS x86-64 systems, you must perform an additional step if you use a copy of an existing system disk as the initial system disk of a new node that is being added to a cluster.

In addition to tasks such as modifying the SCSNODE and SCSSYSTEMID parameters and changing the label on the new system disk, you must also change the label for the memory disk. Follow these steps: