) state. If this condition persists, contact your authorized Stratus service representative for assistance. These Release Notes are for everRun Release 7.5.1.1 (updated at 9:55 PM on 4/29/2021). See the following sections:
The Stratus Customer Service Portal provides a searchable Knowledge Base with technical articles about all Stratus products, including everRun. In some cases, the Release Notes directly reference these Knowledge Base articles (for example, KB-nnnn). You can access the Customer Service Portal and the Knowledge Base articles by using your existing service portal credentials, or by creating a new user account, as follows.
To access the Knowledge Base
Log on to the Stratus Customer Service Portal at https://support.stratus.com.
If needed, create a new account as follows:
Enter your company email address and contact info, and click Register.
Your company email address must include a domain name (for example, stratus.com) for a company that is a registered customer of Stratus.
If you need assistance creating an account, contact your authorized Stratus service representative.
In the Keyword Search box, enter keywords associated with the information you need, and then click Search.
To search for an article by its KB-nnnn number, click Advanced Search. Next to Search by ID, type the article ID number (nnnn) and click Display.
EV-48352: Heartbeat process is leaking memory.
EV-48353: Heartbeat process restart can lead to shared file system corruption.
EV-48354: Heartbeat process restart can lead to 100% full shared file system (/shared), leaving the everRun Availability Console inaccessible.
EV-48355: Heartbeat can crash and is slow to recover during a managed restart.
EV-48387: Upgrade qualify script enhanced to check for valid shared file system and heartbeat configuration.
EV-48402: Not all heartbeat processes are killed on a heartbeat restart.
EV-46765: Nodes may fail to return to service after power loss.
EV-47079: A fresh install of everRun Release 7.5.0.5 can leave a second logical disk stuck as foreign on one node if 4K data drives are present.
EV-47788: The eAC may become inaccessible after system power loss.
EV-47803: A spine restart may cause a false "Node has Rebooted" alert.
EV-47824: The fatal alert "A sensor on node0 (or 1) is indicating a fatal problem" can be seen when it should not be.
EV-47853: Upgrading to everRun Release 7.5.0.5 on a system with 4K data drives can leave logical disks in an unusable state that if repaired can lead to data loss.
EV-47858: Insulate volume replication status and epoch values against node power loss.
EV-47865: The heartbeat configuration file /etc/ha.d/ha.cf can be truncated on node power loss resulting in heartbeat and spine failing to start and the node failing to join the cluster.
Major new features and enhancements are listed below under the release in which they became available.
everRun Release 7.5.1.1 is for bug fixes. See Bug Fixes for information. See also Known Issues for additional issues.
everRun Release 7.5.1.0 is for bug fixes. See Bug Fixes for information.
everRun Release 7.5.0.5 includes the following new features:
You can upgrade to the current release from everRun Release 7.4.x.x by following the instructions in Upgrading everRun Software.
When upgrading from everRun Release 7.4.x.x to Release 7.5.x.x, consider the following:
External storage is not supported.
everRun Release 7.5.x.x or higher no longer supports external storage. If you need to upgrade a system that includes external storage, contact your authorized Stratus service representative for assistance.
Eject any VCDs or USB media from the VMs before upgrading.
If VCD or USB media is still connected to the VMs, it prevents the system from migrating the VMs and putting the PMs into maintenance mode for the upgrade process.
Update the Red Hat VirtIO drivers in any existing Windows-based VMs after upgrading the system.
After upgrading to Release 7.5.x.x, update the VirtIO drivers in your Windows-based VMs to the latest supported versions to ensure the proper operation of your VMs. Download and install the supported drivers from the everRun support site, as described in Updating the VirtIO Drivers (Windows-based VMs).
Reboot any existing VMs to take advantage of performance improvements.
After upgrading to Release 7.5.x.x , reboot the VMs on the system at your earliest convenience to take advantage of the performance improvements in the upgraded QEMU hypervisor.
Refresh web browser after upgrade to ensure up-to-date everRun Availability Console displays.
After an upgrade, various console displays may be incorrect due to files cached in the web browser. For example, the Reprovision Virtual Machine wizard may display incorrect values. To correct the display, reload it by pressing Ctrl-F5.
You can upgrade to the current release from everRun Release 7.3.4.x by following the instructions in Upgrading everRun Software. If you are upgrading from an everRun release prior to Release 7.3.4.x, you must upgrade to Release 7.3.4.x first, and then upgrade to Release 7.5.x.x.
When upgrading from everRun 7.3.4.x or previous releases to everRun Release 7.5.x.x, consider the following:
One View Console and Disaster Recovery are not supported.
If your everRun system is registered with the One View Console, you must unmanage the system before upgrading. If your VMs are protected by Disaster Recovery, you must unprotect the VMs, and then unmanage the everRun system before upgrading. For information on completing these tasks, see the One View and Disaster Recovery online help.
Nagios monitoring solutions are not supported.
everRun Release 7.4.x.x or higher no longer supports Nagios monitoring, which was a technology preview in everRun 7.3.x.x. Nagios add-ons are automatically removed during the upgrade process.
External storage is not supported.
everRun Release 7.5.x.x or higher no longer supports external storage. If you need to upgrade a system that includes external storage, contact your authorized Stratus service representative for assistance.
everRun Release 7.4.x.x or higher requires more disk space than previous releases.
everRun Release 7.4.x.x or higher requires more disk space than previous releases to accommodate changes for the host OS. The amount of space required to upgrade from Release 7.3.4.x to 7.5.x.x can be up to 10 GiB per logical system disk. To verify that your Release 7.3.4.x system meets the upgrade requirements, upload the Release 7.5.x.x upgrade kit on the Upgrade Kits page of the everRun Availability Console. Uploading the kit gives you access to the Qualify button that you can click to run qualification checks. (Note that the Qualify button is available only in 7.3.4.x or higher.) For more information about using the Qualify button and upgrading your system, see Upgrading everRun Software.
Eject any VCDs or USB media from the VMs before upgrading.
If VCD or USB media is still connected to the VMs, it prevents the system from migrating the VMs and putting the PMs into maintenance mode for the upgrade process.
Update the Red Hat VirtIO drivers in any existing Windows-based VMs after upgrading the system.
After upgrading to Release 7.5.x.x, update the VirtIO drivers in your Windows-based VMs to the latest supported versions to ensure the proper operation of your VMs. Download and install the supported drivers from the everRun support site, as described in Updating the VirtIO Drivers (Windows-based VMs).
Any manually added RPMs or customized host OS configuration settings are lost.
When you upgrade from Release 7.3.4.x, the system performs the upgrade by reinstalling the everRun software on each node and restoring any settings associated with everRun features and management. However, the upgrade does not preserve any supplementary packages (for example, Dell OpenManage) or customized settings (for example, SNMP monitoring, SSH keys) that you may have implemented. If applicable, make note of any customizations and manually restore them after the upgrade.
Any manually added IPtables port filtering changes are lost.
everRun Release 7.4.x.x or higher includes improved IPtables port filtering, which you manage in the everRun Availability Console. As a result of the changes, upgrading will overwrite any settings you have manually entered in the host OS. If applicable, make note of any customizations and manually restore them after the upgrade. Use only the everRun Availability Console to configure IPtables filtering in Release 7.4.x.x or higher.
Guests with an attached USB will fail to migrate during an upgrade. This prevents the upgrade from proceeding, leading to a failed upgrade.
When you replace a PM in an everRun system, you must re-activate the product license for the system to register the new PM with the system. The new PM cannot exit maintenance mode and run VMs until the everRun license is re-activated.
After replacing the PM, when the new PM is running (in Maintenance) on the Physical Machines page, open the Preferences page, click Product License, and expand License Check and Activation. Click Check License Now to automatically activate the license (as described in Managing the Product License). When the license is activated, click Finalize to exit maintenance mode.
Beginning in Release 7.5.1.1, everRun software no longer supports CentOS Releases 6.4, 6.5, and 6.6, nor RHEL Releases 6.4, 6.5, and 6.6 as guest operating systems. See Compatible Guest Operating Systems for the list of supported releases of guest operating systems.
For other important considerations about everRun systems, see Important Physical Machine and Virtual Machine Considerations.
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.
VM imported to system with USB 3.0 HUB crashes when started on the everRun system.
The system cannot create application-consistent snapshots of VMs running Windows 2008 (32 bit) and Windows 2003 (32 bit). The system can create only crash-consistent snapshots of VMs running these operating systems.
If you use the P2V client (virt-p2v) to migrate a PM or VM running Windows, the migration may fail with the message, "error: inspection could not detect the source guest (or physical machine)." For more information about this issue, see KB-9401.
If you use the P2V client (virt-p2v) to migrate a PM or VM from a source that is running VMware, the network driver might fail to install properly during the migration process, which leaves the VM network offline. If this happens, manually install the network driver in Device Manager. For instructions, see the Troubleshooting section of Migrating a Physical Machine or Virtual Machine to a System.
If you import a Windows-based VM with the Import/Restore Virtual Machine Wizard, the VirtIO network driver may fail to install properly the first time you start the VM, which leaves the VM network offline. If this happens, manually install the network driver in Device Manager. For instructions, see the Troubleshooting section of Importing an OVF File.
To avoid downtime, before removing a VM, always ensure that both nodes are in the running state and that neither node is in maintenance mode or in the process of synchronizing.
If you remove a VM while one node is shut down in maintenance mode, the operation may stall with the error, "There was a problem deleting vm-name." To correct the problem, you must restart the only running node.
The everRun Availability Console may improperly validate VM names to ensure that they meet the software requirements. If you are creating, reprovisioning, or renaming a VM with an unsuitable name, the operation may fail to execute.
To avoid any problems with VM operations, ensure that your VM names meet the following requirements:
After upgrading an everRun system from Release 7.3.4.x or earlier to Release 7.5.x.x, if you insert a virtual CD (VCD) into a VM as described in Inserting a Virtual CD, the guest operating system may fail to display or mount the VCD.
This issue occurs because the guest OS is still running the QEMU hypervisor from the older version of everRun. To correct the issue, restart the guest operating system, which automatically loads the updated QEMU hypervisor. At your convenience, ensure that you restart the guest OS of each VM on your system to run the updated QEMU hypervisor.
If you are connected to the everRun Availability Console using an https URL in a Microsoft Internet Explorer or 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, and continue with the appropriate procedure below:
In Internet Explorer, the Security Alert wizard appears:
In FireFox, the Your connection is not secure window appears:
Click Confirm Security Exception.
The VNC console appears.
The everRun software on everRun systems does not support the exFAT File system. If you need to mount a USB medium to import or export a VM, as described in Mounting a USB Device or Network-mounted Folder on the everRun System, format the device with NTFS. (By default, most USB media are formatted with the FAT file system, which has a limited file size of 4 GB that may be too small for most VMs.)
If you attempt to recover a missing or failed logical disk with the Repair button in the masthead of the everRun Availability Console, as described in Responding to a Failed Logical Disk, the system may be slow to repair the disk. Although the system successfully removes the failed logical disk from its storage group, it may be slow to migrate the data from the failed disk to other disks in the storage group. The Alerts page may continue to report that the logical disk is not present, that volumes have failed, and that storage is not fault tolerant. Also, the Volumes page may continue to show volumes in the broken () state. If this condition persists, contact your authorized Stratus service representative for assistance.
When you remove a snapshot on an everRun system, the system must coalesce the snapshot by merging it with the next oldest snapshot. While the system is coalescing snapshots:
Avoid removing snapshots if you have an immediate need to perform any of these operations. After you remove a snapshot, wait at least 10-15 minutes before attempting any of these operations, or retry the operation if needed. You may need to wait much longer depending on the size of your volumes, the amount of VM activity, and the number of snapshots you remove.
For information about how to monitor coalescing operations that are underway, see KB-4272.
If you create and delete a snapshot of a volume that is currently in RAW format, the everRun software automatically converts the volume from RAW to QCOW3 (QCOW2v3) format. The conversion is expected because snapshots require QCOW3 format, but consider that changing the volume format may have performance implications for certain VM loads. You cannot convert a volume from QCOW3 back to RAW format.
Features in everRun Release 7.4.0.0 or higher allow you to copy VMs and export VMs that are stopped without requiring a snapshot. If routine snapshots will not be required, consider these alternatives to retain RAW format (and avoid growing the size of volume containers).
If you need to configure the network of an everRun system to work on a different subnet (for example, when shipping to another location or when reconfiguring network subnets), see KB-4264 for instructions.
When configuring the Windows QEMU guest agent, do not enable the option to save a log file during snapshots. If the QEMU guest agent attempts to create a log file during a snapshot, it may cause VSS timeouts that prevent the snapshot from completing.
When you change the IP address or netmask settings of an everRun node as described in Configuring IP Settings, you must reboot the node or the system for the changes to take effect. If you do not reboot the node or the system, both the new and old settings will remain in effect, which may cause routing or connection issues.
If you change the maximum transmission unit (MTU) setting of either business network (network0 or network1) as described in Setting the MTU, the system automatically migrates the VMs from one node to the other. If you change the MTU for network0 specifically, the system also automatically fails over from the primary node to the secondary node.
To avoid this issue, avoid changing the MTU setting of the business networks, or change the MTU only during a planned maintenance period.
Beginning in Release 7.5.1.1, everRun software no longer supports CentOS Releases 6.4, 6.5, and 6.6, nor RHEL Releases 6.4, 6.5, and 6.6 as guest operating systems. So, Compatible Guest Operating Systems no longer lists those releases.
The following changes were made late in the release:
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://support.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.
Product Support and Downloads