| SVAPAR-150198 |
All |
Critical
|
Multiple node warmstarts (causing loss of access to data) may occur on 8.7.1 and 8.7.2 software, when deleting a volume that is in a volume group, and previously received a persistent reservation request.
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
Systems where volumes in a volume group received persistent reservation requests from hosts, while running pre-8.7.1 software. |
| Trigger |
Deletion of a volume that is in a volume group |
| Workaround |
Do not delete any volumes that are inside volume groups prior to upgrading to the fix for this APAR. |
|
8.7.2.1 |
Policy-based High availability, Policy-based Replication, Snapshots |
| SVAPAR-150433 |
All |
Critical
|
In certain policy-based 3-site replication configurations, a loss of connectivity between HA systems may cause I/O timeouts and loss of access to data.
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
Policy-based 3-site replication, where HA was added to an existing asynchronous replication configuration. If asynchronous replication was added to an existing HA configuration, the system is not exposed. |
| Trigger |
Loss of connectivity between HA systems. |
| Workaround |
None |
|
8.7.2.1 |
Policy-based High availability, Policy-based Replication |
| SVAPAR-150764 |
All |
Critical
|
At 8.7.2.0, loss of access to vVols may occur after node failover if the host rebind operation fails.
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
Systems using vVols with 8.7.2.0 |
| Trigger |
Node failover |
| Workaround |
None |
|
8.7.2.1 |
vVols |
| SVAPAR-150663 |
All |
High Importance
|
Some FCM3 drives may go offline on upgrade to 8.7.2.0.
(show details)
| Symptom |
Loss of Redundancy |
| Environment |
Systems with FCM3 product ID 101406B2 or 101406B3 |
| Trigger |
Upgrade to 8.7.2.0 |
| Workaround |
No Value |
|
8.7.2.1 |
Drives |
| SVAPAR-140892 |
FS7300, FS9200 |
Suggested
|
Excessive numbers of informational battery reconditioning events may be logged.
(show details)
| Symptom |
Error in Error Log |
| Environment |
System running > v8.6.0.1 |
| Trigger |
Upgrading to > 8.6.0.1 |
| Workaround |
None |
|
8.7.2.1 |
Reliability Availability Serviceability |
| SVAPAR-151101 |
All |
Suggested
|
Unable to create new volumes in a volume group with a Policy-based High Availability replication policy using the GUI. The error returned is "The selected volume group is a recovery copy and no new volumes can be created in the group."
(show details)
| Symptom |
Configuration |
| Environment |
Systems using Policy-based High Availability where the High Availability volume group was created on software version 8.7.0 or lower and then the system was upgraded to 8.7.1 or higher. |
| Trigger |
Creating new volumes in a volume group with a Policy-based High Availability replication policy using the GUI. |
| Workaround |
The CLI can be used to create and map new volumes. |
|
8.7.2.1 |
Policy-based High availability |
| SVAPAR-131228 |
All |
Critical
|
A RAID array temporarily goes offline due to delays in fetching the encryption key when a node starts up.
(show details)
| Symptom |
Offline Volumes |
| Environment |
Systems using encryption configured to use encryption key servers |
| Trigger |
Start up of a node |
| Workaround |
Reduce the number of configured key servers to two. |
|
8.7.2.0 |
Distributed RAID, Encryption, RAID |
| SVAPAR-140079 |
All |
Critical
|
The internal scheduler is blocked after requesting more flashcopy bitmap memory. This will cause the creation of new snapshots and removal of expired snapshots to fail.
(show details)
| Symptom |
None |
| Environment |
Systems running code level 8.6.1.x, 8.6.2.x, 8.6.3.x and 8.7.0.0 and using Safeguarded Copy or volume group snapshots. |
| Trigger |
When addsnapshot needs to increase IO group memory for the flashcopy feature. |
| Workaround |
A manual 'rmsnapshot' command on an expired snapshot will unblock the scheduler. However it should be noted that if the system has been in this state for a long time, unblocking the scheduler may trigger SVAPAR-140080. |
|
8.7.2.0 |
FlashCopy, Safeguarded Copy & Safeguarded Snapshots |
| SVAPAR-140781 |
All |
Critical
|
Successful login attempts to the configuration node via SSH are not communicated to the remote syslog server. Service assistant and GUI logins are correctly reported.
(show details)
| Symptom |
Configuration |
| Environment |
Systems with syslog configured |
| Trigger |
Configuration node SSH login |
| Workaround |
NA |
|
8.7.2.0 |
Security |
| SVAPAR-141098 |
All |
Critical
|
High peak latency causing access loss after recovering from SVAPAR-140079 and SVAPAR-140080.
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
Any system was exposed to SVAPAR-140079 and SVAPAR-140080 and a recovery procedure was performed. |
| Trigger |
Background deletion of a large number of expired snapshots. |
| Workaround |
After recovery from SVAPAR-140079 and SVAPAR-140080, wait for all expired snapshots to be deleted before starting host IO. |
|
8.7.2.0 |
FlashCopy, Safeguarded Copy & Safeguarded Snapshots |
| SVAPAR-141920 |
All |
Critical
|
Under specific scenarios, adding a snapshot to a volume group could trigger a cluster recovery causing brief loss of access to data.
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
Systems running volume group snapshots |
| Trigger |
Starting a new snapshot for a volume group using the '-pool' parameter. Additionally, the volumes in the volume group need to have a vdisk copy ID equal to 1. |
| Workaround |
Avoid using the '-pool' parameter when taking the snapshot, or add a new vdisk copy with '-autodelete' parameter to the volumes in the volume group that have a vdisk copy ID equal to 1. |
|
8.7.2.0 |
FlashCopy |
| SVAPAR-142287 |
All |
Critical
|
Loss of access to data when running certain snapshot commands at the exact time that a Volume Group Snapshots is stopping
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
Volume Group Snapshots |
| Trigger |
Volume group snapshots being stopped |
| Workaround |
None. |
|
8.7.2.0 |
Snapshots |
| SVAPAR-143997 |
All |
Critical
|
A single node warmstart may occur when the upper cache reaches 100% full while the partner node in the I/O group is offline
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
None |
| Trigger |
Partner node is offline |
| Workaround |
None |
|
8.7.2.0 |
Reliability Availability Serviceability |
| SVAPAR-144389 |
SVC |
Critical
|
In an SVC stretched cluster, adding a second vdisk copy to a PBR-enabled volume using the GUI does not automatically add a copy to the change volume. This can cause subsequent vdisk migration requests to fail.
(show details)
| Symptom |
Configuration |
| Environment |
SVC stretched cluster with PBR |
| Trigger |
Adding a vdisk copy to a PBR-enabled volume in an SVC stretched cluster |
| Workaround |
Manually add the copy to the change volume with the CLI command "addvdiskcopy -mdiskgrp <mdiskgrp_id> <change_volume_vdisk_id>". The -rsize parameter is not needed to make the change volume thin-privisioned, as this is implicit for PBR change volumes. |
|
8.7.2.0 |
Policy-based Replication |
| SVAPAR-147646 |
FS5000, FS5100, FS5200, FS7200, FS7300, FS9100, FS9200, FS9500, SVC |
Critical
|
Node goes offline when a non-fatal PCIe error on the fibre channel adapter is encountered. It's possible for this to occur on both nodes simultaneously.
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
Systems with fibre channel adapters. |
| Trigger |
None |
| Workaround |
None |
|
8.7.2.0 |
Fibre Channel |
| SVAPAR-147870 |
All |
Critical
|
Occasionally, deleting a thin-clone volume that is deduplicated may result in a single node warmstart and a 1340 event, causing a pool to temporarily go offline.
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
Data reduction pools, deduplication and volume group snapshots using thinclones. |
| Trigger |
Deletion of a thin-clone volume that is deduplicated |
| Workaround |
None |
|
8.7.2.0 |
Data Reduction Pools, Deduplication, Snapshots |
| SVAPAR-148049 |
SVC |
Critical
|
A config node may warmstart during the failback process of the online_spare node to the spare node after executing 'swapnode -failback' command, resulting in a loss of access.
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
Any system with hot spare node configured. |
| Trigger |
Running swapnode -failback command |
| Workaround |
None |
|
8.7.2.0 |
Hot Spare Node |
| HU02293 |
All |
High Importance
|
MDisk Groups can go offline due to overall timeout if the backend storage is configured incorrectly after a hot spare node comes online
(show details)
| Symptom |
Offline Volumes |
| Environment |
Environments with hot spare nodes and also have backend storage that is configured incorrectly |
| Trigger |
Hot spare node coming online |
| Workaround |
Correctly map the MDisks to the spare nodes |
|
8.7.2.0 |
Hot Spare Node |
| HU02493 |
SVC |
High Importance
|
On certain controllers that have more then 511 LUNS configured, then mdisks may go offline
(show details)
| Symptom |
Offline Volumes |
| Environment |
Any system that has more than 511 LUNS |
| Trigger |
More then 511 LUNS |
| Workaround |
This problem can be resolved by reducing the LUN count to 511 or below on any effected controller. |
|
8.7.2.0 |
Backend Storage |
| SVAPAR-131999 |
All |
High Importance
|
Single node warmstart when an NVMe host disconnects from the storage
(show details)
| Symptom |
Single Node Warmstart |
| Environment |
Systems using NVMe hosts |
| Trigger |
None |
| Workaround |
None |
|
8.7.2.0 |
NVMe |
| SVAPAR-134589 |
FS9500 |
High Importance
|
Improved error recovery for failed NVMe drives on FlashSystem 9500.
(show details)
| Symptom |
Loss of Redundancy |
| Environment |
None |
| Trigger |
NVMe drive failure |
| Workaround |
None |
|
8.7.2.0 |
Drives |
| SVAPAR-136677 |
All |
High Importance
|
An unresponsive DNS server may cause a single node warmstart and the email process to get stuck.
(show details)
| Symptom |
Single Node Warmstart |
| Environment |
DNS and mail server configured |
| Trigger |
None |
| Workaround |
Reboot the nodes one at a time. |
|
8.7.2.0 |
System Monitoring |
| SVAPAR-137361 |
All |
High Importance
|
A battery may incorrectly enter a failed state, if input power is removed within a small timing window
(show details)
| Symptom |
Loss of Redundancy |
| Environment |
None |
| Trigger |
Removal of input power at the same time a battery power test is in progress |
| Workaround |
Unplug the battery from the node canister and leave it unplugged for at least 10 minutes. Then re-install the battery into the canister.
|
|
8.7.2.0 |
Reliability Availability Serviceability |
| SVAPAR-137512 |
All |
High Importance
|
A single-node warmstart may occur during a shrink operation on a thin-provisioned volume. This is caused by a timing window in the cache component.
(show details)
| Symptom |
Single Node Warmstart |
| Environment |
Systems at 8.7.0.0 with thin-provisioned volumes |
| Trigger |
Shrinking of thin-provisioned volume (possibly because of a FlashCopy mapping being started). |
| Workaround |
None |
|
8.7.2.0 |
Cache |
| SVAPAR-138832 |
All |
High Importance
|
Nodes using IP replication with compression may experience multiple node warmstarts due to a timing window in error recovery.
(show details)
| Symptom |
Multiple Node Warmstarts |
| Environment |
Systems using IP replication with compression |
| Trigger |
No Value |
| Workaround |
No Value |
|
8.7.2.0 |
IP Replication |
| SVAPAR-139247 |
All |
High Importance
|
Very heavy write workload to a thin-provisioned volume may cause a single-node warmstart, due to a low-probability deadlock condition.
(show details)
| Symptom |
Single Node Warmstart |
| Environment |
Systems on 8.7.0 with thin-provisioned volumes |
| Trigger |
Heavy write workload to a thin-provisioned volume |
| Workaround |
None |
|
8.7.2.0 |
Thin Provisioning |
| SVAPAR-139260 |
All |
High Importance
|
Heavy write workloads to thin-provisioned volumes may result in poor performance on thin-provisioned volumes, due to a lack of destage resource.
(show details)
| Symptom |
Performance |
| Environment |
Systems using thin-provisioned volumes in standard pools |
| Trigger |
Heavy write workloads |
| Workaround |
None |
|
8.7.2.0 |
Thin Provisioning |
| SVAPAR-144000 |
All |
High Importance
|
A high number of abort commands from an NVMe host in a short time may cause a Fibre Channel port on the storage to go offline, leading to degraded hosts.
(show details)
| Symptom |
Loss of Redundancy |
| Environment |
Systems configured with NVMe Hosts. |
| Trigger |
ABTSs(Abort Sequence) floods causing driver resource starvation |
| Workaround |
None |
|
8.7.2.0 |
Hosts |
| SVAPAR-144036 |
FS5100, FS5200, FS7200, FS7300, FS9100, FS9200, FS9500 |
High Importance
|
Replacement of an industry standard NVMe drive may fail until both nodes are warmstarted.
(show details)
| Symptom |
Loss of Redundancy |
| Environment |
Systems using industry standard NVMe drives. |
| Trigger |
Replacing a failed industry standard NVMe drive. |
| Workaround |
Warmstart both nodes one at a time. |
|
8.7.2.0 |
Reliability Availability Serviceability |
| SVAPAR-144068 |
All |
High Importance
|
If a volume group snapshot is created at the same time as an existing snapshot is deleting, all nodes may warmstart, causing a loss of access to data. This can only happen if there is insufficient FlashCopy bitmap space for the new snapshot.
(show details)
| Symptom |
Loss of Access to Data |
| Environment |
Systems using volume group snapshots |
| Trigger |
Creating a new volume group snapshot while another is deleting. |
| Workaround |
Increase the FlashCopy bitmap space using chiogrp, so that there is sufficient space for the new snapshot. |
|
8.7.2.0 |
Snapshots |
| SVAPAR-144069 |
All |
High Importance
|
On a system with SAS drives, if a node canister is replaced while an unsupported drive is in the enclosure, all nodes may warmstart simultaneously, causing a loss of access to data.
(show details)
| Symptom |
Multiple Node Warmstarts |
| Environment |
SAS systems with an unsupported drive |
| Trigger |
Node canister replacement |
| Workaround |
Remove the unsupported drive from the enclosure to stabilise the system |
|
8.7.2.0 |
Drives |
| SVAPAR-144070 |
All |
High Importance
|
After changing the system name, the iSCSI IQNs may still contain the old system name.
(show details)
| Symptom |
Configuration |
| Environment |
Systems using iSCSI |
| Trigger |
Changing the system name |
| Workaround |
None |
|
8.7.2.0 |
iSCSI |
| SVAPAR-144272 |
All |
High Importance
|
IO processing unnecessarily stalled for several seconds following a node coming online
(show details)
| Symptom |
Performance |
| Environment |
Systems with a syslog server configured |
| Trigger |
Node restart |
| Workaround |
Remove syslog server |
|
8.7.2.0 |
Performance |
| SVAPAR-145278 |
All |
High Importance
|
Upgrade from 8.7.0 to 8.7.1 may cause to an invalid internal state, if policy-based replication is in use. This may lead to node warmstarts on the recovery system, or cause replication to stop.
(show details)
| Symptom |
Multiple Node Warmstarts |
| Environment |
Systems using policy-based replication |
| Trigger |
Upgrade from 8.7.0 to 8.7.1 |
| Workaround |
Make all recovery volume groups independent before upgrading from 8.7.0 to 8.7.1. |
|
8.7.2.0 |
Policy-based Replication |
| SVAPAR-146097 |
All |
High Importance
|
On systems running 8.7.0 or 8.7.1 software with NVMe drives, at times of particularly high workload, there is a low probability of a single-node warmstart.
|
8.7.2.0 |
Drives |
| SVAPAR-146522 |
All |
High Importance
|
FlashCopy background copy and cleaning may get stuck after a node restarts. This can also affect Global Mirror with Change Volumes, volume group snapshots, and policy-based replication
(show details)
| Symptom |
Configuration |
| Environment |
Systems with FlashCopy maps |
| Trigger |
Node restarts |
| Workaround |
Restart nodes affected by the issue |
|
8.7.2.0 |
FlashCopy, Global Mirror With Change Volumes, Policy-based Replication, Snapshots |
| SVAPAR-148251 |
All |
High Importance
|
Merging partitions on 8.7.1.0 software may trigger a single-node warmstart.
(show details)
| Symptom |
Single Node Warmstart |
| Environment |
Systems running 8.7.1.0 software with partitions |
| Trigger |
Partition merge |
| Workaround |
None |
|
8.7.2.0 |
Policy-based High availability |
| SVAPAR-89331 |
All |
High Importance
|
Systems running 8.5.2 or higher using IP replication with compression may have low replication bandwidth and high latency due to an issue with the way the data is compressed.
(show details)
| Symptom |
Performance |
| Environment |
Systems using IP replication compression |
| Trigger |
None |
| Workaround |
Disable compression on IP partnership |
|
8.7.2.0 |
IP Replication |
| SVAPAR-92804 |
FS5000 |
High Importance
|
SAS direct attach host path is not recovered after a node reboot causing a persistent loss of redundant paths.
(show details)
| Symptom |
Loss of Redundancy |
| Environment |
Mostly seen with ESXi hosts with Lenovo 430-8e SAS/SATA 12Gb HBA (LSI) |
| Trigger |
Node reboot, warmstart. |
| Workaround |
n/a |
|
8.7.2.0 |
Hosts |
| SVAPAR-114758 |
All |
Suggested
|
Following a cluster recovery, the names of some back end storage controllers can be lost resulting in default names such as controller0.
(show details)
| Symptom |
Configuration |
| Environment |
Any with external storage controllers |
| Trigger |
T2 cluster recovery |
| Workaround |
None |
|
8.7.2.0 |
Backend Storage |
| SVAPAR-123614 |
SVC |
Suggested
|
1300 Error in the error log when a node comes online, caused by a delay between bringing up the physical FC ports and the virtual FC ports
(show details)
| Symptom |
Error in Error Log |
| Environment |
System using NPIV |
| Trigger |
Node rejoining the cluster
|
| Workaround |
None |
|
8.7.2.0 |
Hot Spare Node |
| SVAPAR-137322 |
All |
Suggested
|
A false 1627 event will be reported on an SVC stretched cluster after adding connectivity to more ports on a backend controller.
(show details)
| Symptom |
Loss of Redundancy |
| Environment |
Stretched cluster.
|
| Trigger |
Increasing the number of logins to backend controller by adding connectivity to more ports.
A typical scenario would be when transitioning a backend Spectrum Virtualize system from NPIV disabled attachment, through NPIV Transitional to NPIV enabled.
The NPIV transitional phase would allow logins to both the physical and virtual(host) WWPNs, which would increase the number of logins. |
| Workaround |
Reset all nodes in the virtualizing layer(SVC).
This can be done manually one node at a time, or alternatively the software upgrade procedure will reset all nodes. |
|
8.7.2.0 |
Backend Storage |
| SVAPAR-137906 |
All |
Suggested
|
A node warmstart may occur due to a timeout caused by FlashCopy bitmap cleaning, leading to a stalled software upgrade.
(show details)
| Symptom |
Single Node Warmstart |
| Environment |
This can occur on any platform configured with FlashCopy, but it is much more likely to cause an outage on a low end, low core systems. |
| Trigger |
System upgrade |
| Workaround |
Set the clean rate of all the maps to 0 before upgrading, and then reverting them back again afterwards. |
|
8.7.2.0 |
FlashCopy, System Update |
| SVAPAR-138286 |
All |
Suggested
|
If a direct-attached controller has NPIV enabled, 1625 errors will incorrectly be logged, indicating a controller misconfiguration.
(show details)
| Symptom |
Configuration |
| Environment |
Systems with direct-attached controllers which have NPIV enabled |
| Trigger |
No Value |
| Workaround |
No Value |
|
8.7.2.0 |
Backend Storage |
| SVAPAR-138859 |
FS5000, FS5100, FS5200 |
Suggested
|
Collecting a Type 4 support package (Snap Type 4: Standard logs plus new statesaves) in the GUI can trigger an out of memory event causing the GUI process to be killed.
(show details)
| Symptom |
None |
| Environment |
FlashSystem 5xxx |
| Trigger |
Triggering a Snap Type 4: Standard logs plus new statesaves, via the GUI. |
| Workaround |
Prepare and trigger livedumps via the CLI then take an option 3 snap either via the GUI or CLI. In the failure scenario, the GUI will hang but the GUI process will respawn, the snap collection will complete successfully in the background. The snap file can then be copied with scp or via the GUI. |
|
8.7.2.0 |
Support Data Collection |
| SVAPAR-139943 |
All |
Suggested
|
A single node warmstart may occur when a host sends a high number of unexpected Fibre Channel frames.
(show details)
| Symptom |
Single Node Warmstart |
| Environment |
Any system with FC connection to hosts. |
| Trigger |
None |
| Workaround |
None |
|
8.7.2.0 |
Fibre Channel |
| SVAPAR-140588 |
All |
Suggested
|
A node warmstart may occur due to incorrect processing of NVMe host I/O offload commands
(show details)
| Symptom |
Single Node Warmstart |
| Environment |
Any system with NVMe hosts configured |
| Trigger |
None |
| Workaround |
None |
|
8.7.2.0 |
NVMe |
| SVAPAR-142939 |
FS5000 |
Suggested
|
Upgrade to 8.7.1 on FS5045 with policy-based replication or high availability is not supported.
(show details)
| Symptom |
Configuration |
| Environment |
FS5045 with PBR or PBHA |
| Trigger |
Attempted upgrade to 8.7.1 |
| Workaround |
None |
|
8.7.2.0 |
Policy-based Replication |
| SVAPAR-143621 |
All |
Suggested
|
REST API returns HTTP status 502 after a timeout of 30 seconds instead of 180 seconds
(show details)
| Symptom |
None |
| Environment |
Environments using the REST API |
| Trigger |
Running a REST API command that takes longer than 30 seconds |
| Workaround |
None |
|
8.7.2.0 |
REST API |
| SVAPAR-144033 |
All |
Suggested
|
Spurious 1370 events against SAS drives which are not members of an array.
(show details)
| Symptom |
Error in Error Log |
| Environment |
Systems with SAS drives. |
| Trigger |
None |
| Workaround |
None |
|
8.7.2.0 |
Reliability Availability Serviceability |
| SVAPAR-144062 |
All |
Suggested
|
A node may warmstart due to a problem with IO buffer management in the cache component.
(show details)
| Symptom |
Single Node Warmstart |
| Environment |
None |
| Trigger |
None |
| Workaround |
None |
|
8.7.2.0 |
Cache |
| SVAPAR-144271 |
SVC |
Suggested
|
An offline node that is protected by a spare node may take longer than expected to come online. This may result in a temporary loss of Fibre Channel connectivity to the hosts
(show details)
| Symptom |
Loss of Redundancy |
| Environment |
Systems with spare nodes configured |
| Trigger |
A node that is protected by a spare node comes back online |
| Workaround |
None |
|
8.7.2.0 |
Hot Spare Node |
| SVAPAR-144515 |
All |
Suggested
|
When trying to increase FlashCopy or volume mirroring bitmap memory, the GUI may incorrectly report that the new value exceeds combined memory limits.
(show details)
| Symptom |
Configuration |
| Environment |
8.7.0 or 8.7.1 systems using FlashCopy or volume mirroring |
| Trigger |
Trying to increase bitmap space for FC / MR |
| Workaround |
Use CLI to increase bitmap memory |
|
8.7.2.0 |
FlashCopy, Volume Mirroring |
| SVAPAR-146064 |
All |
Suggested
|
Systems using asynchronous policy-based replication may incorrectly log events indicating the recovery point objective (RPO) has been exceeded.
(show details)
| Symptom |
Error in Error Log |
| Environment |
Systems with volume groups configured with asynchronous policy-based replication |
| Trigger |
A short interruption to replication |
| Workaround |
None |
|
8.7.2.0 |
Policy-based Replication |
| SVAPAR-146640 |
All |
Suggested
|
When volume latency increases from below 1ms to above 1ms, the units in the GUI performance monitor will not be incorrect.
(show details)
| Symptom |
None |
| Environment |
Systems running 8.7.x |
| Trigger |
Volume latency increasing from below 1ms to above 1ms |
| Workaround |
Refresh the GUI cache |
|
8.7.2.0 |
Graphical User Interface |
| SVAPAR-93445 |
FS5100, FS5200, FS7200, FS7300, FS9100, FS9200, FS9500 |
Suggested
|
A single node warmstart may occur due to a very low-probability timing window related to NVMe drive management.
(show details)
| Symptom |
Single Node Warmstart |
| Environment |
Systems with NVMe Drives |
| Trigger |
None |
| Workaround |
None |
|
8.7.2.0 |
No Specific Feature |