everRun Release 7.2.2.0 Release Notes

These release notes are for everRun release 7.2.2.0 (updated at 1:33 PM on 4/22/2021). See the following sections:

• Important Considerations
• Known Issues
• New Features, Enhancements, and Bug Fixes
• Getting Help

Important Considerations

Upgrading from Previous Releases of everRun

You can upgrade from any prior everRun release (listed on the Downloads page at http://www.stratus.com/go/support/everrun) to everRun release 7.2.x with no VM downtime by following the instructions in Upgrading everRun Software.

If you are upgrading from a release not listed on the everRun Support page (for example, a beta release) you must perform a complete system re-install.

A DR-Protected VM Cannot Be Deleted

A DR-protected VM cannot be deleted. After shutting down a DR-protected VM, the Remove button will not appear. To delete such a VM, use the One View Console to disable DR protection for that VM. After DR protection is removed, the Remove button will be enabled and you can use the everRun Availability Console to shut down and remove the VM.

Updating Guest VM Software After Installing a VM

After installing a VM, check to see if updates to the guest OS are available. If updates are available, install them.

Do Not Update CentOS Host OS Directly from CentOS

Do not update the CentOS host OS software directly from CentOS. Use only the CentOS release that is installed along with everRun software.

Optimizing Performance of A-Link Networks

Stratus recommends that you enable jumbo frames on A-Link networks by setting their Ethernet frame MTU size to 9000 bytes (by default, they are set to 1500 bytes). Doing so improves VM performance and reduces host processing overhead.

The A-Link networks must:

• Be a single Ethernet cable, point-to-point connection, or
• Have intermediate components (for example, switches) that are all fully capable of passing jumbo frame traffic

Use AVCLI commands to enable jumbo frames. AVCLI is installed on the host system along with everRun software. You can run AVCLI by logging onto the host through a remote console using the system IP address. Alternatively, you can install AVCLI on a remote management computer. For information about how to install AVCLI on a remote computer, see AVCLI Command Overview.

To set A-Links to use jumbo frames:

1. From a remote console, issue the network-info command to determine the name(s) of the A-Link network(s). In the command's output, look for the names of networks that have role = A-Link . See network-info for an example.

2. Issue the network-change-mtu command to change the MTU size to the maximum value of 9000 bytes. The change takes effect immediately. The following example changes the sync_2003 and sync_2004 A-Link networks to use jumbo frames.

   avcli network-change-mtu sync_2003 sync_2004 9000
3. Issue the network-info command to verify that the A-Links now have MTU values of 9000.

Migrating a PM or VM to an everRun System

Migrating Windows 2012 R2 or Windows 8.x PMs or VMs from a non-everRun system to an everRun system is not supported. For a list of PM and VM operating systems that you can migrate, see Migrating a Physical Machine or Virtual Machine to an everRun 7.x System.

Status of RAID Physical Disks Is Not Monitored

everRun software does not monitor the state of physical disks in a RAID set. You must use the tools supplied by the RAID controller vendor to monitor the health and status of individual physical disks in a RAID set.

Other Important everRun Considerations

For important considerations about everRun systems, see Important Physical Machine and Virtual Machine Considerations.

Known Issues

Windows 2008 (pre-R2) Guests May Crash

Windows Server 2008 (pre-R2) VMs are at risk of crashing and can exhibit the following symptoms:

• Bug Check 0x19: BAD_POOL_HEADER (see http://msdn.microsoft.com/en-us/library/windows/hardware/ff557389(v=vs.85).aspx for more information).
• Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION (see http://msdn.microsoft.com/en-us/library/windows/hardware/ff558949(v=vs.85).aspx for more information).

Under heavy disk loads, such as during a back up, Windows Server 2008 x64 pre-R2 (NT 6.0, Vista kernel) crashes with the symptoms listed above.

Guest VMs running other Windows versions, including Windows Server 2008 R2 and Linux do not exhibit these symptoms.

Do not install or import Windows Server 2008 pre-R2 guests on everRun systems. Instead install one of the following supported Windows types which do not exhibit these symptoms:

• Windows Server 2008 R2 (NT6.1, Windows 7 kernel) x64
• Windows Server 2012 (NT6.2, Windows 8 kernel) x64
• Windows Server 2012 R2 (NT6.3, Windows 8.1 kernel)

If you already use Windows Server pre-R2 guests, monitor them for the symptoms described above. Install a replacement VM of one of the Windows types mentioned above for any VM that must run reliably. If crashes do not impact you, it is likely that crashes will occur as load on your VM increases.

Simplex PM Does Not Reboot After an everRunUpgrade

When upgrading a simplex system (single PM) from everRunRelease 7.2.0.0, the upgrade process completes but the system does not reboot. To reboot a simplex system after it's upgrade completes, click System in the left-hand navigation panel then click Reboot.

VMs May Not Boot If One Node is Removed From System

If you remove one PM from the system (by clicking Work On and then clicking Remove), do not place the remaining PM into maintenance and then bring it back into service by just using the Finalize button. Doing so will prevent all VMs from being able to boot. If you must place the remaining PM into maintenance mode, reboot it before you return it to service. See Rebooting a Physical Machine for details.

The VM Console Button Does Not Work With Java 8

The Console button on the Virtual Machines page does not work when Java 8 is installed on the remote management computer running the everRun Availability Console. To avoid this problem, do not install Java 8 on the remote management computer. Instead use Java 7.

Uploading an Upgrade Kit Will Fail If The User Session Times Out

Uploading an upgrade kit will fail if the user session on the everRun Availability Console times out during the upload process. This might occur, for example, when upgrading a DR PM through the primary PM's site over a low-bandwidth or heavily congested DR link. If the upload process is taking a long time, you can avoid the problem by performing an action in the everRun Availability Console (like clicking to view a different page) before the session times out. Alternatively you can perform the upload locally at the site of the system being upgraded.

A VM Exported With Only Some of its Snapshotted Volumes Cannot be Imported

During a VM export operation, be sure to select all of the VMs volumes. Doing so exports a VM that can then be imported at a later time.

Removing User or DR Snapshots Temporarily Prevents Some VM and DR Operations

When either a user or the Disaster Recovery (DR) software removes 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:

• A user cannot create a new snapshot in the everRun Availability Console. If you try, an error indicates that the system is busy.
• The DR software cannot create DR snapshots of the primary VM. If DR snapshots are delayed long enough, DR protection may temporarily fall below your snapshot retention and recovery point objective (RPO) thresholds until DR snapshots resume.
• A user cannot start the VM associated with the snapshot(s) if the VM is currently stopped. The Start button is temporarily unavailable on the Virtual Machines page of the everRun Availability Console.
• A user cannot enable or resume DR protection for a VM. An alert on the Alerts page of the everRun Availability Console may indicate that there is not enough storage space for the snapshot, because the coalescing snapshots continue to occupy space in the volume container(s) until they are finally removed.

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 DR-protected VMs, if DR snapshot replication appears to stop or fall below your thresholds, check the Alerts page of the everRun Availability Console for more information.

Coalescing Snapshots Can Affect RPO

When snapshots are coalescing, new snapshots cannot be taken until coalescing completes. If the RPO is set to be near or lower than the typical coalesce time for a VM's activity level, the VM will periodically fall out of RPO. This is unlikely to happen on systems with moderate work load and RPOs in the 1 - 6 hour range but should this occur, it is necessary to increase the RPO time to avoid falling out of RPO.

The ftxmt Script Does Not Work With CIFS as Documented

When creating and mounting an export share on a Windows (CIFS) share, type y in response to the question Does this share require authentication?. Then enter the guest user name (usually guest) and password.

Moving an everRun System to a Different Subnet

Use the following procedure to prepare the management IP configuration of an everRun system to work on a different subnet (for example when shipping to another location or when reconfiguring network subnets).

1. In the everRun Availability Console, click Physical Machines in the left-hand navigation panel, and note which node is the primary node.
2. Connect a VGA console directly to the primary node.
3. On the VGA console, press Enter. The console displays several addresses. Note the PM's link-local IPv6 address (it is the one that begins with fe80::).
4. In the management computer's browser, enter the URL of the link-local IPv6 address in the form http://[ipv6-link-local-address]. Be sure to include the address within brackets, for example: http://[fe80::21c:23ff:fedd:30ed].
5. Place both nodes into maintenance mode. Log on to the everRun Availability Console and in the left-hand navigation panel, click Physical Machines.
   1. Select the secondary node (the one not marked primary) and click Work On.
   2. Select the primary node and click Work On.
6. Click Preferences in the left-hand navigation panel, and click IP Configuration.
   1. Change the IP configuration settings to match the addresses for the new subnet to which the system will be moved.
   2. Click Save.
7. Click System in the left-hand navigation panel, then click Shutdown.
8. Move the everRun system to the new location and/ or connect it to the new subnet.
9. Power on both PMs.
10. On a management computer, connect to the everRun Availability Console using the IPv4 management address you specified in step 6.
11. Remove both nodes from maintenance mode. In the left-hand navigation panel, click Physical Machines.
    1. Select one node and click Finalize.
    2. Select the other node and click Finalize.

Under Certain High Workloads Windows VM Snapshots May Not Be Application-Consistent

In some high workload situations, the Windows QEMU guest agent may become unresponsive, preventing snapshots of Windows VMs from being application-consistent (instead they are only crash consistent as indicated on the Summary tab of the Snapshots page). If this occurs, application-consistent snapshots will not longer be possible until the Windows QEMU quest agent is restarted. Perform the following procedure to restore application-consistent snapshot capability.

1. In the Windows Task Manager stop the QEMU Guest Agent (qemu-ga.exe) process.

2. In the Windows Services user interface, start the QEMU Guest Agent service.

Specifying a Log File While Installing the Windows QEMU Guest Agent May Cause VM Timeouts

Do not specify a log file while installing qemu-ga.exe. Doing so may cause VSS timeouts when snapshots are being taken.

Replacing Physical Machines, Motherboards, NICs, or RAID Controllers

In the event of a hardware failure requiring replacement of an entire PM, everRun supports PM replacement while VMs continue to run on the other PM, thereby avoiding any guest downtime. The procedure for doing this is documented in Replacing Physical Machines, Motherboards, NICs, or RAID Controllers. After completing this procedure, perform the following steps to avoid any potential subsequent problems.

1. The preferred PM setting can get corrupted after replacing a PM. It is not possible to tell which VMs may be impacted by this, so you must perform steps a. and b. below for each VM.
   1. In the everRun Availability Console, change the preferred PM setting to the node that the VM is not currently on. See Load Balancing and Selecting a Preferred PM for a Virtual Machine for information about how to do this.
   2. Then change the preferred PM of each VM back to the desired setting.
2. If, after performing the previous step, an alert appears saying that a rebalance must be performed, on the everRun Availability Console masthead, click Rebalance ().

Unsupported Network Adapter Card and Chip

Due to the issue outlined at http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=migr-5093183, everRun does not support the following network adapter card and chip:

• The Broadcom NetXtreme II Dual Port 10GBase-T Network Adapter, IBM part number 49Y7910
• Any other NICs that use the Broadcom BCM57712 Ethernet hardware chip

Do Not Use the ifdown Command

Do not issue the ifdown command from an everRun physical machine's host OS to temporarily bring down a VM's business (ibizx) network connection. Doing so will disconnect the physical interface from its bridge and cause the VM to become unreachable over the network. Instead, use the ifconfig down command.

New Features, Enhancements, and Bug Fixes

Major new features, enhancements, and/or bug fixes are listed below under the release in which they became available.

Fixed in everRun Release 7.2.2.0

• bz-29135 - Modules fail to recompile when upgrading base OS.

• bz-29069 - Unable to Grant Access to User using active directory

• bz-28948 - The SNMP OID var sraSiOverallSystemStatus is not correctly set and is a regression from the previous release.

• bz-28927 - Node crashes running scenarios on Dell 630 and Dell 730 Haswell platforms

• bz-28907 - VM is stuck in snapshot state after powering off and powering on

• bz-29027 - Date and Time not updated correctly on secondary node

• bz-29014 - Fix to 26664 overrides much of the AX's split-brain protection

• bz-29255 - VMs cannot start on SuperMicro server (AES bit)

• bz-29248 – Address glibc GHOST security hole CVE-2015-0235

• bz-29211 - Available memory calculations for VM creation, reconfiguration, and startup are incorrect

• bz-29259 – CPU ucode update causes problems on IBM Haswell servers

• bz-29065 - Address NTP vulnerabilities CVE-2014-9296, CVE-2014-9295, CVE-2014-9294, CVE-2014-9293

Fixed in everRun Release 7.2.1.0

• bz-28701 - Selecting the Identify button for a NIC that does not support the identify feature during everRun software installation, causes the installation to abort (and the physical machine to reboot).

New in everRun Release 7.2.0.0

• Disaster Recovery (optional feature, requires separate license)
• Virtual machine snapshots
• Import and Restore snapshots
• Export virtual machine snapshot
• Simplex everRun system (in DR configurations only)
• Support for 24 VMs (up to 4 of these can be FT VMs)
• In-place upgrade of Avance and everRun MX systems to everRun
• Reset MTBF of VMs
• Parallel Redundancy Protocol (PRP)
• Active Directory
• Support for disks larger than 2 terabytes

Getting Help

If you have a technical question about everRun software, you can find the latest documentation at the Downloads page at http://www.stratus.com/go/support/everrun.

If you are unable to resolve your questions with the online documentation, and the system is covered by a service agreement, please contact everRun Customer Support or your authorized Stratus service representative. For information, see the everRun Support page at http://www.stratus.com/services-support/customer-support.