The indicated vdisk was quarantined to prevent writing invalid data that may exist on the controller that logged this event.
Warning Event 485.
The indicated vdisk was quarantined to prevent writing invalid data that may exist on the controller that logged this event.
This event is logged to report that the indicated vdisk has been put in the quarantined offline state (status of QTOF) to prevent loss of data. The controller that logged this event has detected (via information saved in the vdisk metadata) that it may contain outdated data that should not be written to the vdisk. Data may be lost if you do not follow the recommended actions carefully. This situation is typically caused by removal of a controller module without shutting it down first, then inserting a different controller module in its place. To avoid having this problem occur in the future, always shut down the Storage Controller in a controller module before removing it.
If event 486 is not logged at approximately the same time, reinsert the removed controller module, shut it down, then remove it again.
If events 485 and 486 are both logged at approximately the same time, wait at least 5 minutes for the automatic recovery process to complete. Then sign in and confirm that both controller modules are operational. (You can determine if the controllers are operational with the show redundancy-mode CLI command or the System Redundancy table in the System Overview panel of the SMU.) In most cases, the system will come back up and no further action is required. If both controller modules do not become operational in 5 minutes, data may have been lost. If both controllers are not operational, follow this recovery process:
Remove the controller module that first logged event 486.
Turn off the power for the controller enclosure, wait a few seconds, then turn it back on.
Wait for the controller module to restart, then sign in again.
Check the status of the vdisks. If any of the vdisks have a status of quarantined offline (QTOF), dequarantine those vdisks.
Reinsert the previously removed controller module. It should now restart successfully.
| Target | MSA.System | ||
| Category | Alert | ||
| Enabled | True | ||
| Alert Generate | True | ||
| Alert Severity | Warning | ||
| Alert Priority | Low | ||
| Remotable | False | ||
| Alert Message |
|
| ID | Module Type | TypeId | RunAs |
|---|---|---|---|
| Event | DataSource | MSA.DataSource.Event.System | Default |
| EventFilter | ConditionDetection | MSA.ConditionDetection.Filter.Event | Default |
| Alert | WriteAction | System.Health.GenerateAlert | Default |
Home<Rule ID="MSA.Rule.Event.System.Warning.485" Enabled="true" Target="MSA.System" ConfirmDelivery="true" Remotable="false" Priority="Normal" DiscardLevel="100">
<Category>Alert</Category>
<DataSources>
<DataSource ID="Event" TypeID="MSA.DataSource.Event.System"/>
</DataSources>
<ConditionDetection ID="EventFilter" TypeID="MSA.ConditionDetection.Filter.Event">
<EventCode>485</EventCode>
<SeverityNumeric>2</SeverityNumeric>
</ConditionDetection>
<WriteActions>
<WriteAction ID="Alert" TypeID="Health!System.Health.GenerateAlert">
<Priority>0</Priority>
<Severity>1</Severity>
<AlertMessageId>$MPElement[Name="AlertMessageID870524dcc48f47f3b45be42d1a522c31"]$</AlertMessageId>
<AlertParameters>
<AlertParameter1>$Target/Property[Type="System!System.Entity"]/DisplayName$</AlertParameter1>
<AlertParameter2>$Target/Property[Type="MSA.System"]/PrimaryIP$</AlertParameter2>
<AlertParameter3>$Target/Property[Type="MSA.System"]/SecondaryIP$</AlertParameter3>
<AlertParameter4>$Data/Property[@Name='severity']$</AlertParameter4>
<AlertParameter5>$Data/Property[@Name='message']$</AlertParameter5>
</AlertParameters>
</WriteAction>
</WriteActions>
</Rule>