everRun Release 8.1.1.0 Release Notes

These Release Notes (updated at 1:20 AM on 10/29/2026) are for everRun Release 8.1.1.0.

See the following sections:

New Features and Enhancements

everRun Release 8.1.1.0 includes the following new features:

New Features in Previous Releases

For a list of features introduced in:

Features No Longer Supported

Legacy Upgrade Paths No Longer Supported

Starting with everRun Release 8.1.1.0, upgrade methods that re-image a node are no longer supported. This includes the legacy migration path from CentOS to Ubuntu, and the legacy Ubuntu recovery re-image path.

Before attempting to upgrade, your system must be running at least the minimum supported everRun release of 8.0.0.0. If your system is on an older, CentOS-based release, you must first upgrade to a supported Ubuntu-based baseline (see Upgrading from everRun Release 7.x to 8.x or Higher). Then, apply the Release 8.1.1.0 upgrade kit from the everRun Availability Console.

Bug Fixes

Upgrade Now Verifies that Priv0 Is Isolated

When the private network (priv0) is not isolated, it can result in system management issues and degraded VM stability. However, in previous releases, the upgrade process proceeded when the private network (priv0) was not isolated.

In everRun Release 8.1.1.0, the upgrade process checks for external hosts on priv0. If priv0 is not isolated, the upgrade stops and the following Alert is displayed: The software upgrade failed for the following reason(s): Release information verification error.

For information on resolving the priv0 Network Isolation error before upgrading, see KB0017923 (Release Information Validation Error - Resolving a priv0 Network Isolation Error During Upgrade Prequalification Checks).

Restriction on Number of Virtual CPUs in Windows 11 Environments

In previous releases, in Windows 11 guest environments, the number of vCPUs could not exceed 8. Exceeding this limitation may have resulted in system hangs or data corruption.

This issue has been fixed in everRun.

Note: Before upgrading to Release 8.1.1.0, shut down all Windows 11 VMs so that the fix is correctly applied.

VM Creation Fails When Using a Remote ISO (NFS or CIFS) If the File Path Contains Spaces

Previously, the system used a validation check that did not allow whitespace characters in the remote ISO path. This caused VM creation to fail with an "Invalid file path" error if any folder or file name in the path included a space (for example, a folder named Windows IoT).

In everRun Release 8.1.1.0, spaces in remote ISO paths are now allowed, ensuring compatibility with standard naming conventions for network shares. Spaces in the .iso file name continue to be unsupported.

Upgrade Process Now Validates SSD Life Remaining

On everRun 200i and 250i systems running Release 8.1.0.x, the Solid State Drive (SSD) Life remaining check was not working correctly, and would report 100% life remaining when in fact more had been used. To prevent outages and protect data, the upgrade process now detects and blocks upgrades when SSD life used is 95% or higher.

After upgrading to everRun Release 8.1.1.0, the SSD Life remaining reading in the everRun Availability Console is accurate. This appears on the Sensors tab of the Physical Machines page.

Cannot Attach USB Device to Unprotected VM

Previously, if you tried to attach a USB device to an unprotected VM on the Virtual Machines page of the everRun Availability Console, the operation failed.

This issue has been fixed in everRun Release 8.1.1.0.

Logical Disks Become Foreign on Node After Power Interruption

Previously, if both nodes in an everRun system lost power asynchronously, all logical disks in one of the nodes might become marked as foreign. The node recovery process preserved all data, but it re-created the /boot and root file systems and re-installed the everRun system software.

This issue has been fixed in everRun Release 8.1.1.0.

Bugs Fixed in everRun Release 8.1.0.2

For information, see Bug Fixes in everRun Release 8.1.0.2.

CVE Fixes

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

Important Considerations

This section describes important information related to installing, upgrading, and running everRun Release 8.1.1.0: 

Upgrading to everRun Release 8.1.1.0

To upgrade to everRun Release 8.1.1.0, see Upgrading everRun Software Using an Upgrade Kit.

Caution: Consider contacting your authorized Penguin Solutions 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 Penguin Solutions service representative for assistance as soon as possible to avoid complications and potential data loss.

Dell PowerEdge Systems and UEFI0074 Prompt During Installation

During a fresh installation or autoinstall using the Ubuntu 24.04-based image on Dell PowerEdge servers, the system may display the following Dell UEFI firmware prompt during the second reboot of the everRun installation sequence:

UEFI0074: The Secure Boot policy has been modified since the last time the system was started. Review the Secure Boot policy settings in System Setup > System BIOS > Security Settings. If policy changes were expected, no action is necessary. Otherwise, modify the Secure Boot policy settings as needed.

This is an expected, informational Dell firmware notification, not a everRun installation failure or Secure Boot signature verification error. The notification occurs once during initial provisioning and does not reappear during normal system operation or subsequent reboots.

Dismiss the prompt and allow the system to proceed. Normal boot and installation continues without impacting BIOS security configurations. If the prompt halts an automated install pipeline, temporarily set Secure Boot to Disabled in Dell System Setup (F2 > System BIOS > Security Settings) during the initial deployment, and re-enable it after the OS installation completes.

Requirements for Upgrading Windows 10 Virtual Machine Guest Systems to Windows 11

Before you can upgrade a Windows 10 Virtual Machine guest system to Windows 11, the following requirements must be met on the Windows 10 guest system:

If the guest system does not meet these requirements, contact a Penguin Solutions service representative for assistance.

For information about enabling Secure Boot State and vTPM security, see Understanding Windows 11 Virtual Machine Differences from Other VMs.

REST API Restrictions for Importing a VM

If you import a virtual machine by using the POST /v2/import/importvm method of the REST API, observe the following restrictions:

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 v3 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

Fault-Tolerant VM Becomes Stuck After Rapid USB Detach and Re-Attach

Rarely, a VM can enter an inconsistent state if you detach a USB storage device from a VM, then re-attach it immediately. This occurs only when the VM is configured for fault tolerance, and the USB storage device is re-attached within one second (while synchronization is in progress and the standby node is becoming active).

To avoid this issue, do not attach the USB storage device immediately after detaching it from the VM. Wait until the VM finishes synchronizing.

If this issue occurs, follow the procedure below to restore the VM and re-enable fault tolerance:

  1. Set the VM's preferred node to the node where the VM is currently active.

  2. Power off the VM and wait until it is completely stopped.

  3. Unplug the USB storage device from the node.

  4. In the everRun Availability Console, wait until that disk no longer appears in the USB section on the Physical Machines page.

  5. If automatic load balancing is required, reset the load balancing setting on the preferred node to automatically balance (see Load Balancing).

  6. Power on the VM.

  7. Wait until synchronization successfully completes and fault tolerance is restored.

  8. If needed, plug the USB storage device into the node again.

This problem will be fixed in a future release.

Rolling Reboot Hangs Indefinitely When a VM Has an Attached USB Storage Device

Initiating a rolling reboot on a system where a VM has an attached USB storage device causes the rolling reboot process to stall indefinitely. The rolling reboot starts, but the process fails during node evacuation because VMs with attached USB storage devices cannot be migrated to the peer node.

To avoid this problem, before initiating a rolling reboot detach all USB storage devices from all VMs and verify that VM synchronization is healthy.

If this condition occurs, cancel or stop the rolling reboot, detach the USB storage device from the VM, wait for VM synchronization to complete, then restart the rolling reboot.

This problem will be fixed in a future release.

Backup of Stopped Virtual Machine Triggers Unnecessary Warning

When using the everRun Availability Console to back up a stopped VM, the following Warning appears: This backup is crash consistent and not necessarily application consistent. Any inflight transaction will be available in subsequent backups. During the backup you may observe some performance impact.

This warning is valid when backing up running VMs, but it is not applicable for stopped VMs, and you can safely ignore it. This issue will be fixed in a future release.

Duplicate VirtIO VCD Created After Power Cycles

Following power cycles of the system nodes, a duplicate VirtIO Virtual CD (VCD) may be created for a virtual machine. The extra VirtIO entry appears on the Virtual CDs page of the everRun Availability Console and remains stuck in the synchronizing state.

To resume normal operations, manually delete the duplicate VirtIO VCD from the VM configuration.

Intermittent Snaphot Creation Failure on Windows Server 2022 Virtual Machines

Creating a snapshot of a Windows Server 2022 guest VM may intermittently fail. This occurs when the guest operating system's Volume Shadow Copy Service (VSS) exceeds its 10-second write-hold threshold during snapshot preparation, particularly during periods of high disk I/O or shortly after container and disk resizing. This timeout is enforced internally by Windows VSS, so host-side timeout adjustments are not possible.

The workaround is to wait until guest I/O activity subsides and the VM is idle, then retry the snapshot operation.

Mismatch in OVA File Name Validation Between everRun Availability Console and REST API

Due to inconsistent string verification between the REST API and the everRun Availability Console, it is possible for Open Virtual Appliance (OVA) file names and VM names that contain special characters (such as &) to be imported via the REST API, even though they are restricted in the everRun Availability Console. These special characters can cause XML parsing errors that prevent system audit logs from displaying on the Audit Logs page of the everRun Availability Console.

To avoid this issue, ensure that OVA files and VM names adhere to standard everRun Availability Console naming restrictions, and omit special characters when invoking REST API import operations. See the naming conventions described in Creating a New Virtual Machine.

VM Import Succeeds With Invalid Destination Parameter

When using the REST API to import a virtual machine (VM) from a Virtual CD (VCD), the VM import operation succeeds even if invalid data is specified in the destination parameter. In a future release of everRun, the REST API will return an error if the destination parameter is invalid.

Swagger UI Accepts Invalid Authorization Tokens Without Immediate Error Message

When authorizing in the REST API Swagger UI (/v2/login), entering an invalid or improperly copied token allows authorization to proceed without displaying an error. The interface shows the session as authorized (displaying the Logout button), but subsequent API requests fail with a 401 Unauthorized error. To avoid this issue, ensure that you copy the full, exact authentication token returned by /v2/login and paste it into the authorization field.

UEFI Debian VMs Fail to Boot After P2V Conversion

UEFI-based Debian virtual machines (versions 10.10, 11, and 12.8) may fail to boot following a Physical-to-Virtual (P2V) conversion. Although P2V conversion succeeds and the UEFI VM is created, the VM does not boot on the target device. Instead, boot processes stop in the UEFI shell.

P2V Conversion Fails for Rocky Linux Version 9.4

Physical-to-virtual migration (P2V conversion) is not supported for Rocky Linux 9.4 guests, because the version of virt-v2v (1.44.2) included in everRun Release 8.1.1.0 does not support that distribution. The process terminates with the error: virt-v2v: error: virt-v2v is unable to convert this guest type (linux/rocky).

A version of virt-v2v that supports Rocky Linux guests will be included in a future everRun release.

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.

Unable to Create Application-Consistent Snapshot for Ubuntu 24.04.1 VM

If you try to create an application-consistent snapshot of a VM with the Ubuntu 24.04.1 guest operating system, the system creates a crash-consistent snapshot even if you have installed the qemu-guest-agent package.

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 Penguin Solutions 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, select qcow2 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.

Graphical Installation Fails to Start When Installing Debian 11 Guest

If you install the Debian 11 guest operating system, the guest fails to start the graphic installation utility and the installation terminates with a fatal error. To resolve this issue, see KB0017035.

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

Before migrating a PM or VM using the 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.

AVCLI Import or Restore of VM with Two VHDX Volumes Fails

If you use the avcli vm-import or avcli vm-restore commands to import or restore a virtual machine with two VHDX volume files, the operation fails. If needed, use the everRun Availability Console to import or restore the VM.

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 KB0017168.

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.

Thermald “Unsupported CPU model or platform” Messages During Node Startup

On some systems, syslog may show thermald (thermal daemon) messages at node or system startup such as Need Linux PowerCap sysfs and Unsupported cpu model or platform. These messages are expected, and indicate that thermald is present but not needed for your existing hardware. The messages do not indicate a fault or thermal risk.

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:

  1. Reboot the system and open the BIOS configuration utility.

  2. Remove the original EFI boot entries from the BIOS settings.

  3. Save the updated settings and restart the system.

  4. 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 Penguin Solutions service representative.

Cannot Attach USB Device to VM on First Attempt

If you try to attach a USB device to a VM on the Virtual Machines page of the everRun Availability Console, the system might fail to detect valid partitions and attach the device on the first attempt. To work around the issue, disconnect and reinsert the USB device.

Incomplete Messages When Creating or Importing a Windows 11 Guest with the BIOS Boot Type

When you create or import a VM with the Windows 11 guest operating system, the VM must have the UEFI boot type as described in Understanding Windows 11 Virtual Machine Differences from Other VMs. If you create or import a Windows 11 guest with the BIOS boot type, the system appears to create the new VM successfully, but the VM cannot start. If you attempt to start the VM, the system automatically shuts down the VM and displays a message on the Summary tab of the Virtual Machines page to explain that the VM name cannot start because it has a misconfigured boot type BIOS. To select the correct boot type (UEFI), you must delete the VM and create a new one.

When this happens, the Dashboard and Alert History page might display incomplete information, such as a blank message, or a message that incorrectly states VM name failed to boot and will be restarted though the VM will be shut down. The messages also fail to explain how to create a VM with the correct boot type (UEFI).

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.

Accessing Knowledge Base Articles

The Penguin Solutions 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 Penguin Solutions 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 Penguin Solutions Customer Service Portal at https://support.penguinsolutions.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 Penguin Solutions 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.penguinsolutions.com/services-support/downloads/?tab=everrun. You can also search the Knowledge Base in the Penguin Solutions Customer Service Portal at https://support.penguinsolutions.com.

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