everRun Release 8.0.0.0 Release Notes

These Release Notes (updated at 12:09 AM on 4/23/2025) are for everRun Release 8.0.0.0. See the following sections:

New Features and Enhancements

New in everRun Release 8.0.0.0

The following features are new in everRun Release 8.0.0.0:

VM Backup and Recovery (Technology Preview)

The new VM backup and recovery feature is a Technology Preview only and is under development for potential availability in a future release. Access to the feature requires a separate license and is disabled by default. The feature is not supported nor intended for use in production environments. Contact your authorized service provider for more information.

For information about how the proposed VM backup and recovery feature might work, see Backing Up a Running Virtual Machine and Recovering a Virtual Machine from a Backup.

Features No Longer Supported

The following features and products are not supported with everRun Release 8.0.0.0 or higher:

Bug Fixes

Bugs Fixed in everRun Release 8.0.0.0

ZTC-20585: Guest shutdown can result in guest volume being marked inconsistent.

ZTC-19756: Unable to restore an OVF/VHDX VM with the Import/Restore button.

ZTC-18685: Reserved name for VM is not checked at VM creation and generates subsequent error conditions.

ZTC-17370: The drbd5 service port 8905 is not defined in the iptables utility.

ZTC-17177: Missing Ethernet PCI slot prevents UI from rendering the portal, UI remains stuck on loading.

ZTC-17175: Setting MTU 9000 on the P1 interface will cause Link DOWN and then UP again, but all network traffic stops through the P1 interface.

ZTC-17164: Opening a VNC console in UI, seeing port:0 instead of port:8000.

ZTC-17161: Exported VMs may show incorrect network ordering and MAC address settings in the Import/Restore Virtual Machine Wizard.

ZTC-16990: SMART information for NVMe disks and gdisk data are missing from buggrab results.

ZTC-16733: Upgrade is hung if there is a node already in maintenance mode. Update Qualify script to check for this.

ZTC-17133: libvirt log files can grow indefinitely.

ZTC-17128: Increase SSH Root Public Key length from 2048 to 4096 for increased security.

ZTC-17126: Installed software on system with AMD processors and VM testing failed to function correctly.

ZTC-20626: Add Dubai/UAE Timezone Configuration in UI.

ZTC-21795: Customer Requests to be able to modify the UI inactivity timeout.

ZTC-21225: Include Activated_License_Key_Download_assetID.htm file when generating a diagnostic file.

ZTC-19150: Alert reports network status for priv0 incorrectly for short duration of time.

ZTC-17938: Eliminate appearance of upgrade failures and unnecessary calls to support.

ZTC-17901: When priv0 is lost, VNC console will not work when the VM is active on secondary node.

ZTC-17136: ntpd_periodic_restart has an error for the ntpdate command, which cannot be found in PATH.

ZTC-17314: Customer is able to create more than 32 VMs, but if 33rd one is activated, it will not start.

ZTC-17455: Any attempt to create a snapshot results in a popup that says FAILED_TO_SNAP_VOLUMES.

ZTC-18314: System management architecture should permit proper cold start initialization when ibiz0 is working but priv0 is not.

ZTC-20585: When a snapshot is issued, only one side is created.

ZTC-1903: Bug grabs should abort if either node is in swap. This includes all levels.

ZTC-11759: When creating a VM with the Copy option, the created VM always enters the running state.

ZTC-17181: A delete snapshot request did not result in a merge on node0 until almost 24 hrs later.

ZTC-3011: Extend the buggrabber default timer.

ZTC-9961: Scanner is detecting that python is vulnerable because it is no longer receiving security updates.

ZTC-11817: VMs do not start if each node is issued a Work On then Shutdown, and the first node to be powered off is powered on first followed by the other node.

ZTC-3011: Exclude both process core files and Linux kernel panic vmcore from the FULL buggrab.

CVE Fixes

For a list of the CVE fixes, see Fixed CVEs.

Important Considerations

Upgrading to Release 8.0.0.0

Caution: Consider contacting your authorized Stratus service representative for assistance before upgrading your system from everRun Release 7.x to 8.x. They can help you to evaluate your system, ensure that it meets the prerequisites, locate any potential restrictions, and, if needed, discuss a strategy for the upgrade. If you encounter any problems during the upgrade process, contact your authorized Stratus service representative for assistance as soon as possible to avoid complications and potential data loss.

To upgrade to everRun Release 8.0.0.0, follow the upgrade path for the release that is running on your system:

After upgrading to everRun Release 8.0.0.0, to upgrade to a later 8.x.x.x maintenance release, see Upgrading everRun Software Using an Upgrade Kit.

SNMP Disabled by Default on everRun Systems

SNMP is disabled by default on everRun systems. Starting with everRun Release 7.9.0.0 or higher, the SNMP process is also stopped in the console operating system on each node. For security reasons, if you need to enable SNMP, you should disable SNMP v1 and v2, and enable only version 3 by using the SNMP Restricted configuration. For details, see Configuring SNMP Settings and Security Hardening, as well as KB0015445.

Tested Guest Operating Systems

For a list of the guest operating systems tested with the current release, see Tested Guest Operating Systems. For information on guest operating systems tested or supported in previous releases, go to http://everrundoc.stratus.com, select the appropriate release, and then search for the guest operating system.

Known Issues

everRun Installation Fails on First Boot on a System with Virtual Drives

If you install the everRun software on a system with virtual drives created and initialized with Fast Initialization, the installation fails with a fatal error, for example:

FATAL ERROR: Error 5 creating everrun-root lv

To work around this issue, reboot the system and continue with the installation. The installation program will try to continue and perform one more reboot before the actual installation starts.

everRun Installation Fails on a Previously Installed System with EFI Boot Entries

If you install the everRun software on a system that was previously installed with everRun, the installation might fail with grub-install errors on the physical console of the system because it cannot overwrite the original EFI boot entries. For example, the grub-install error messages might appear similar to the following:

Stderr: Installing grub to /boot/efi.
Installing for x86_64-efi platform.
grub-install: warning: Cannot set EFI variable Boot000A.
grub-install: warning: efivarfs_set_variable: writing to fd 8 failed: Invalid argument.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Invalid argument.
grub-install: error: failed to register the EFI boot entry: Invalid argument.

To work around this issue, reboot the system and open the BIOS configuration utility. Remove the original EFI boot entries from the BIOS settings. Save the updated settings, restart the system, and restart the installation process. For information about accessing and modifying BIOS configuration settings for a system, see the vendor documentation for the system hardware. If you need assistance, contact your authorized Stratus service representative.

everRun Legacy BIOS Installation with Virtual Floppy Starts from sdb Disk

The everRun software installation typically configures the system to boot from the sda disk device; however, on a system that is configured with Legacy BIOS and a virtual floppy disk, sda is reserved for the floppy disk; therefore, the system boots from the sdb disk device.

Upgrading from Release 7.x to 8.x Does Not Preserve System Logs from Original 7.x System

When you upgrade from everRun Release 7.x to 8.x, the upgrade process does not preserve the system logs from the original Release 7.x (CentOS) system. To preserve the log data before upgrading, create a diagnostic file as described in Creating a Diagnostic File and download it to a management PC.

Unknown Error in everRun Availability Console After Starting Upgrade from Release 7.x to 8.x

When you start an upgrade from everRun Release 7.x to 8.x, after you shut down node1 and click Upgrade to upgrade node0, the everRun Availability Console might display an alert that "An unknown error has occurred." You can safely ignore this message and click OK to continue the upgrade.

Timeout Alert in everRun Availability Console After Canceling and Restarting Upgrade from Release 7.x to 8.x

When you start an upgrade from everRun Release 7.x to 8.x, cancel the upgrade, and then restart the upgrade, the everRun Availability Console might display an alert that the "Pre-upgrade hook failed with a timeout while waiting for pre_upgrade completion status." If you click OK and then restart the upgrade by clicking Upgrade again, the upgrade proceeds normally.

Windows Server Guest Stuck in Booting State After Upgrading from Release 7.x to 8.x

After upgrading from everRun Release 7.x to 8.x, in rare cases, a Windows Server guest might remain stuck in the booting state, waiting for its storage to be ready. As a workaround, stop and start the VM to allow it to continue booting.

Lengthy VM Volume Synchronization After Upgrading from Release 7.x to 8.x

After upgrading from everRun Release 7.x to 8.x, the volumes associated with some VMs might take longer than normal to synchronize between nodes because the system performs a full mirror copy of each volume instead of a delta mirror copy. The amount of time required for synchronization varies by system hardware, overall system load, and guest disk activity.

Windows Server 2022 Guest Uses Windows Server 2016 VirtIO Drivers

When you install VirtIO drivers in a Windows Server 2022 guest operating system as described in Updating the VirtIO Drivers (Windows-based VMs), the system installs the VirtIO drivers associated with Windows Server 2016. The Windows Server 2022 guest performs normally with these drivers.

Remote Desktop Session to Windows Server 2022 Guest Hangs

In rare cases, a Remote Desktop session to a Windows Server 2022 guest hangs. As a workaround, you can open a connection to the console of the guest by selecting the guest on the Virtual Machines page and clicking Console.

No Statistics Available for Node on System Page of everRun Availability Console

On the System page of the everRun Availability Console, under Node0 or Node1, the system displays no statistics for a node even though the node is currently running.

To display statistics for the node

  1. In the everRun Availability Console, open Preferences and then IP Configuration.

  2. Record the IP address for the node that lacks statistics.

  3. Open an SSH connection to the node as described in Accessing the Host Operating System.

  4. Run the following command to restart the collectd service that provides the statistics.

    # systemctl restart collectd

everRun Availability Console Displays HTTP 500 Error After Putting Primary Node Into Maintenance

If you put the primary node of an everRun system into maintenance mode and both nodes in the system lose power asynchronously (one node loses power and restarts, and then the next node loses power and restarts), the everRun Availability Console might display an HTTP Status 500: Internal Server Error page because the web server files on the system have been corrupted.

To correct the issue and restore access to the everRun Availability Console

  1. Open an SSH connection to the primary node as described in Accessing the Host Operating System.

  2. Delete the Apache Tomcat org folder by executing the following command:

    # rm -rf /opt/apache-tomcat-9.0.55/work/Catalina/localhost/ROOT/org/

  3. Refresh the web browser to display the everRun Availability Console.

Logical Disks Become Foreign on Node After Power Interruption

If both nodes in an everRun system lose power asynchronously (one node loses power and restarts, and then the next node loses power and restarts), all logical disks in one of the nodes might become marked as foreign. For example, on the Physical Machines page, when you select the node and click the Storage tab, all logical disks in the node are displayed as Foreign in the Storage Group column. No VM data is lost, but the system data on the affected node is corrupted, and you must recover the node to clear the alerts.

To recover a node with foreign disks

  1. Put the node with foreign logical disks into maintenance mode.

  2. Force boot each VM on the system so that it begins to run on the primary node.

  3. Perform a node recovery of the node with foreign logical disks, as described in Recovering a Failed Physical Machine.

The node recovery process preserves all data, but it re-creates the /boot and root file systems, re-installs the everRun system software, and allows the node to rejoin the system.

DVD/USB Recovery or Replacement Fails on System with 512e, 512n and 4K Logical Disks

If you use DVD/USB recovery (Recovering a Failed Physical Machine) or replacement (Replacing Physical Machines, Motherboards, NICs, or RAID Controllers) on a node in an everRun system with 512e, 512n, and 4K logical disks, the operation might fail with a FATAL ERROR. If this happens, contact your authorized Stratus service representative for assistance.

Guest Performance Issues with Large Guest Volumes

Guest volumes that are 2TB or greater in size and that become fragmented over time may significantly reduce guest performance. When volumes of this size are created, Stratus recommends that qcow2 be selected as the disk image format. The format qcow2, instead of raw, reduces performance slightly, but prevents the significant performance reduction seen with raw guest volumes of this size. For information on creating guest volumes, see Creating a Volume in a Virtual Machine.

Windows Server 2016 Guest Stuck in Booting State After Installation in Localized German Language

After installing Windows Server 2016 with the localized German version of the Windows Installer (ISO) in a VM with a single virtual network adapter, the VM is stuck in the booting state because its network is not working. To resolve this issue, see KB0017020.

Removable Media and Migrating a PM or VM Using the P2V Client

Before migrating a PM or VM using a bootable P2V client (virt-p2v) ISO file, check if any removable media (for example, floppy disks, DVD drives, or external USB disks) are attached to the source image. If removable media are attached to the source image when you attempt to migrate a PM or VM, the error message Conversion failed appears. To prevent this issue, deselect the media in the virt-p2v window before starting the migration. To do so, access the virt-p2v window with the sections Target properties and Fixed hard disks, and then beneath Fixed hard disks, uncheck the box in the Convert column next to the removable media. See Migrating a Physical Machine or Virtual Machine to a System, particularly the section To migrate a PM or VM to the everRun system, for more information on using virt-p2v.

"The VM name has failed to start" Alert While Running the P2V Client Is Normal

While using the P2V client to migrate a VM from an everRun or ztC Edge system, it is normal if the source system displays the alert "The VM name has failed to start" during the migration process, because although the source VM is powered on and running the P2V client, the guest operating system does not start.

Unknown Error in everRun Availability Console When Importing an Unprotected VM

When you an import an unprotected VM (see Unprotected Operation), the everRun Availability Console might display an alert that "An unknown error has occurred." You can safely ignore this message and click OK to continue the import.

Maximum Path Length When Importing a VM

When you import a VM using the Import/Restore Virtual Machine wizard, the maximum length of the path to the VM, including the VM name, is 4096 characters for the import options Import from remote/network Windows Share(CIFS/SMB) and Import from remote/network NFS.

Maximum Resolution of a UEFI VM Console Session

On the Virtual Machines page of the everRun Availability Console, you can open a VM console session to display the console of the guest operating system running in the VM. When you open a console session to access a guest VM with a UEFI boot type, the console session may have a maximum resolution of 800x600. If needed, you can configure a higher resolution in the BIOS setup utility, as described in KB0017012.

Creating VCD fails When Console Browser is Microsoft Edge

When you are using Microsoft Edge as the browser for the everRun Availability Console you cannot create a VCD: the process will fail. Instead, use another compatible browser (see Compatible Internet Browsers).

Mapping of Japanese Keyboards 106 and 109 For Console in Firefox May Be Incorrect

The mapping of the Japanese keyboards 106 and 109 may be incorrect when using Firefox to access the everRun Availability Console. Use Chrome or remote connection software (VNC or RDP), instead.

Cannot Enable SNMP Requests Without Traps

If you create an SNMP request in the everRun Availability Console, you must also create a trap; otherwise, the everRun Availability Console displays the error "Problem encountered updating SNMP. Make sure your settings are correct. Error: Configure SNMP failed." As a workaround, when creating a new SNMP request, click Enable SNMP Requests and Enable SNMP traps, do not define a Version 3 user, keep the default of Restricted requests, and specify at least one trap recipient. Adding a Version 3 user or clicking Unrestricted during the initial configuration might cause the configuration to fail. After the initial configuration is complete, you can then modify it to specify any settings that you require.

System Fails to Generate SNMPv3 Traps When Authentication Is Enabled

If you configure an SNMPv3 user and send SNMP traps with authentication enabled, the system fails to generate the SNMP traps.

VMs Running Windows 2016 with the Maximum vCPUs and Memory Will Not Reboot Cleanly

A Windows 2016 VM with the maximum supported number of vCPUs and the maximum amount of memory will not reboot cleanly. To avoid the problem, reboot the VM using the Shutdown button (on the Virtual Machines page, in the bottom pane for the VM), and then restart the VM using the Start button. To avoid the problem, reduce the number of vCPUs or the amount of memory assigned to the VM.

Some Browsers Unable to Connect a VNC When Using https

If you are connected to the everRun Availability Console using an https URL in some browsers, including the Mozilla® Firefox® browser, and you click Console after selecting a running VM from the Virtual Machines page, the message VNC: Unable to connect, retrying in n seconds may appear. To enable the VNC connection, click the https link to the VNC console page in the upper right-hand corner of the masthead. In the Firefox browser, when the Your connection is not secure window appears:

  1. Click Advanced. A message about an invalid security certificate appears.
  2. Click Add Exception. The Add Security Exception dialog box appears with the console's location in Location.

  3. Click Confirm Security Exception.

The VNC console appears.

Some Browsers Unable to Connect a VNC When Using http

If you are connected to the everRun Availability Console using an http URL in some browsers, including the Google® Chrome™ browser, and you click Console after selecting a running VM from the Virtual Machines page, the message VNC: Unable to connect, retrying in n seconds may appear. If you cannot establish a connection, try using either the Mozilla Firefox or Microsoft Edge browser.

Reboot Required when Changing Node IP Address or Netmask Network Settings

When you change the IP address or netmask settings of a node as described in Configuring IP Settings, both the old and new settings are in effect until you reboot the node. Having both settings active may cause routing or connection issues.

Accessing Stratus Knowledge Base Articles

The Stratus Customer Service Portal provides a searchable Knowledge Base with technical articles about all Stratus products, including everRun. In some cases, the online Help directly references these Knowledge Base articles (for example, KBnnnnnnn). You can access the Stratus Customer Service Portal and its Knowledge Base by using your existing portal credentials, or by creating a new user account, as follows.

To access the Knowledge Base

  1. Log on to the Stratus Customer Service Portal at https://service.stratus.com.

    If needed, create a new account as follows:

    1. Click Register.

    2. Enter your contact information including your company email address and registration code, and then click Submit.

      Your company email address must include a domain name (for example, stratus.com) for a company that is a registered customer of Stratus. The portal sends an email to administrators of the company's account to approve the request.

    3. Upon approval, click the link in the email that you receive from Stratus.
    4. Enter a new password and finish configuring your account.

    If you need assistance creating an account, contact your authorized Stratus service representative.

  2. In the portal, do one of the following:

    • In the Search box, enter keywords or the KB article number (KBnnnnnnn) associated with the information you need, and then click the search button.
    • Click Knowledge, click the name of a product, and then browse available articles.

Getting Help

If you have a technical question about everRun systems, you can find the latest technical information and online documentation at the Downloads page at https://www.stratus.com/services-support/downloads/?tab=everrun. You can also search the Knowledge Base in the Stratus Customer Service Portal at https://service.stratus.com.

If you cannot resolve your questions with these online resources, and the system is covered by a service agreement, contact your authorized Stratus service representative. For information, see the everRun Support page at https://www.stratus.com/services-support/customer-support/?tab=everrun.