Failed Virtual Disk
The causes and resolutions refer to the Dell Modular Disk Storage Manager recovery guru. Launch Dell Modular Disk Storage Manager to diagnose and fix the recovery failure as follows:
Open Start >> Programs >> Dell >> MD Storage Manager >> Modular Disk Storage Manager Client.
If the MD Storage Array is already being managed by MDSM, you can proceed with the Causes and Resolution sections.
From Edit -> Add Storage Array, provide the IP address of the MD Storage Array and Add it to the discovered devices configuration in order to manage it.
Select the MD Storage Array and follow the steps specified in this recovery guru.
One or more virtual disks on the storage array have failed. The Recovery Guru Details area provides specific information you will need as you follow the recovery steps.
Caution: Possible loss of data accessibility. Do not remove a component when either (1) the Service Action (removal) Allowed (SAA) field in the Details area of this recovery procedure is NO, or (2) the SAA LED on the affected component is OFF (note that some products do not have SAA LEDs). Removing a component while its SAA LED is OFF may result in temporary loss of access to your data. Refer to the following Important Notes for more detail.
Caution: Electrostatic discharge can damage sensitive components. Always use proper antistatic protection when handling components. Touching components without using a proper ground may damage the equipment.
Important Notes
You may be able to recover data from a failed virtual disk. Whether or not this is possible depends on how the failure occurred. You can use this procedure to restore data in two ways: contacting your Technical Support Representative to attempt a data recovery, or restoring data from backup media.
If the virtual disk is marked failed because you replaced the wrong physical disk during a degraded virtual disk recovery procedure, you have not lost data. Follow the recovery procedure to reinsert the physical disk and return the virtual disk to the Degraded state.
This problem could happen if one or more physical disks comprising the disk pool or disk group have failed, causing the associated virtual disks to fail. However, there may be situations, such as unreadable sectors, where you can have a failed virtual disk even if the physical disks associated with the virtual disk are Optimal. Follow the recovery procedure to identify the status of the associated physical disks and the appropriate recovery steps.
All I/O to the affected virtual disks will fail.
To the Operating System (OS), a failed virtual disk is exactly the same as a failed non-RAID physical disk. Refer to the operating system documentation for any special requirements concerning failed physical disks and perform them where necessary.
Make sure the replacement physical disks have a capacity equal to or greater than the failed physical disks you will remove in the following steps.
You can replace the failed physical disks while other disk pools and disk groups on the storage array are receiving I/O. Service Action Allowed Important Information:
The Service Action (removal) Allowed field in the Details area indicates whether or not you can safely remove the component. If the SAA field is NO, then the affected component must remain in place until you service another component first.
The Service action LED on Component field in the Details area indicates whether or not a physical SAA LED is present on the hardware component. This field does NOT indicate whether the LED is ON or OFF (that indication is provided by the Service action (removal) allowed field).
If a component does not have an SAA LED, then it is OK to remove the component when its fault LED is lit and the Service Action (removal) Allowed field = YES in the Details area.
The Service Action (removal) Allowed field shown in the Details area and the physical SAA LED on the hardware component (if supported) MUST match before you remove the affected component. In rare cases (such as multiple problems), the status of the LED and the SAA field may not match. If there is a mismatch, then you should NOT remove the component until these indications match.
1 | In the Array Management Window (AMW), verify the status of the physical disks associated with the failed virtual disks:
| ||||||||||||||||||||||||||||||||||||||||||
2 |
| ||||||||||||||||||||||||||||||||||||||||||
3 | Important: You will delete the disk pool or disk group later in these recovery steps. If you wish to re-create the disk pool or disk group later using the same configuration, select the Monitor > Reports > Storage Array Profile menu option and then click the Save As button to save a copy of the Storage Array Profile. Make sure the "Storage" option is selected in the Save As dialog. There are several different types of virtual disks that can exist in a disk pool or disk group. Use the Recovery Guru details area to determine the affected disk pool or disk group. Then, find the disk pool or disk group on the Storage and Copy Services tab in the AMW. Use the information provided by the AMW to determine the types of virtual disks on the affected disk pool or disk group. Step through every entry in the following table and perform all procedures associated with the virtual disk type combination for the affected disk pool or disk group.
| ||||||||||||||||||||||||||||||||||||||||||
4 | Locate all failed physical disks associated with this disk pool or disk group (the fault indicator lights on the failed physical disks should be lit). Note: To determine the associated physical disks, select one of the affected virtual disks (identified in the Details area) on the Storage and Copy Services tab in the AMW. Each associated physical disk will have an association dot underneath it. | ||||||||||||||||||||||||||||||||||||||||||
5 | Remove each failed physical disk. | ||||||||||||||||||||||||||||||||||||||||||
6 | Wait 30 seconds, then insert the new physical disks into the same slots (if you want to keep the disk pool or disk group on physical disks in the same slot locations). The fault indicator light on the new physical disks may become lit for a short time (one minute or less). Note: Wait until the replaced physical disks are ready (fault indicator light off) before going to step 7. | ||||||||||||||||||||||||||||||||||||||||||
7 | Important: All data on the disk pool or disk group will be lost once you complete this step. Be sure that you have an adequate backup, or go back to step 1 if you want to attempt data recovery.
| ||||||||||||||||||||||||||||||||||||||||||
8 |
| ||||||||||||||||||||||||||||||||||||||||||
9 |
| ||||||||||||||||||||||||||||||||||||||||||
10 | Add the virtual disks in the new disk pool or disk group back to the operating system. You may need to reboot the system to see the virtual disks. Note: Do not start I/O to these virtual disks until after you restore from backup. | ||||||||||||||||||||||||||||||||||||||||||
11 | Restore the data for the new virtual disks from backup. | ||||||||||||||||||||||||||||||||||||||||||
12 | Click the Recheck button to rerun the Recovery Guru. The failure should no longer appear in the Summary area. If the failure appears again, contact your Technical Support Representative. |
| Target | Microsoft.SystemCenter.ManagementServer | ||
| Category | Alert | ||
| Enabled | True | ||
| Alert Generate | True | ||
| Alert Severity | Warning | ||
| Alert Priority | Normal | ||
| Remotable | True | ||
| Alert Message |
|
| ID | Module Type | TypeId | RunAs |
|---|---|---|---|
| DS | DataSource | Microsoft.Windows.ScriptGenerated.EventProvider | Default |
| Alert | WriteAction | System.Health.GenerateAlert | Default |
| WriteToDW | WriteAction | Microsoft.SystemCenter.DataWarehouse.PublishEventData | Default |
Home
<Rule ID="Dell.MDStorageArray.ABBXMLEvent17" Enabled="onEssentialMonitoring" Target="SystemCenter!Microsoft.SystemCenter.ManagementServer" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
<Category>Alert</Category>
<DataSources>
<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.ScriptGenerated.EventProvider">
<ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<ScriptName>RBODEventGenerator</ScriptName>
<EventNumber>17</EventNumber>
</DataSource>
</DataSources>
<WriteActions>
<WriteAction ID="Alert" TypeID="SystemHealth!System.Health.GenerateAlert">
<Priority>1</Priority>
<Severity>1</Severity>
<AlertMessageId>$MPElement[Name="Dell.MDStorageArray.ABBXMLEvent17.StringResource"]$</AlertMessageId>
<AlertParameters>
<AlertParameter1>$Data/EventDescription$</AlertParameter1>
</AlertParameters>
<Suppression>
<SuppressionValue>$Data/EventDisplayNumber$</SuppressionValue>
<SuppressionValue>$Data/Channel$</SuppressionValue>
<SuppressionValue>$Data/PublisherName$</SuppressionValue>
<SuppressionValue>$Data/LoggingComputer$</SuppressionValue>
<SuppressionValue>$Data/EventCategory$</SuppressionValue>
<SuppressionValue>$Data/EventLevel$</SuppressionValue>
<SuppressionValue>$Data/UserName$</SuppressionValue>
<SuppressionValue>$Data/EventNumber$</SuppressionValue>
<SuppressionValue>$Data/EventDescription$</SuppressionValue>
</Suppression>
<Custom1/>
<Custom2/>
<Custom3/>
<Custom4/>
<Custom5/>
<Custom6/>
<Custom7/>
<Custom8/>
<Custom9/>
<Custom10/>
</WriteAction>
<WriteAction ID="WriteToDW" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishEventData"/>
</WriteActions>
</Rule>