Hardware Controllers & Enclosures
The Controllers & Enclosures section covers the physical layer beneath a storage pool: the HBA or RAID controller cards in each appliance, the drive enclosures attached to them, and the individual drive bays. Use it to see what hardware QuantaStor has discovered, to work out which physical bay a given drive sits in, and to diagnose a controller or enclosure that is not reporting itself correctly.
This page is about the hardware view. For the operating system's view of the same drives -- device paths, SMART data, formatting, scanning -- see Physical Disks/Devices. For the path layer stacked on top of a shared SAS enclosure, see Multipath Configuration. For pool layout and pool-level hot spares, see Storage Pools.
| Section | Purpose |
|---|---|
| What QuantaStor discovers | The five object types, and how discovery works |
| HBAs and RAID controllers | Which card type to use for which kind of pool |
| Controller properties and firmware | Reading a controller's reported detail |
| Enclosures, layouts and the slot map | The enclosure diagram, and how a bay is identified |
| Identifying a drive in the chassis | Blinking a drive or an empty bay |
| Enclosure services (SES) | What SES provides and what it needs |
| Hardware hot spares | Hot spares at the controller level |
| Firmware version checking | The media firmware blocklist |
| Hardware RAID units | Creating, importing and caching RAID units |
| When an enclosure or slot map is wrong | Diagnosing bad or missing enclosure data |
| CLI reference | The qs commands for this area
|
What QuantaStor discovers
QuantaStor models the hardware layer as five object types, all of them discovered rather than configured:
| Object | What it represents |
|---|---|
| Hardware Controller | One HBA or RAID card. Carries the model, firmware and BIOS revisions, serial number, SAS address, and counts of ports, drives and RAID units. |
| Hardware Enclosure | A drive chassis or expander behind a controller, with its bay count, drive count and reported fan, power-supply and temperature-sensor counts. |
| Hardware Disk | A drive as the controller sees it -- bay position, controller-reported status, vendor, model, serial, SAS address, drive temperature and SMART verdict. This is a different object from the Physical Disk that the operating system sees; the two are correlated by serial number and VPD identifier, and each Hardware Disk carries the ID of its Physical Disk. |
| Hardware RAID Unit | A logical drive built by a RAID controller. Always empty on a plain HBA. |
| Hardware Alarm | A controller-reported event. Also always empty on a plain HBA. |
Discovery is done by a set of vendor plug-ins, one per controller family, each of which drives that vendor's own command-line utility. The mapping from plug-in to utility lives in qs_hwadapter.conf, and the plug-in that claims a card becomes its Controller Group:
| Controller Group | Utility | Cards |
|---|---|---|
ADAPTEC_RAID |
arcconf |
Adaptec / Microsemi RAID |
ARECA |
areca64 |
Areca RAID |
DELL_BOSS |
mvcli |
Dell BOSS boot cards |
DELL_PERCCLI |
perccli64 |
Dell PERC |
HP_SMARTARRAY |
ssacli |
HPE Smart Array |
LSI_STORCLI |
storcli64 |
LSI / Broadcom MegaRAID and the newer SAS HBAs |
SAS_HBA |
sas2ircu or sas3ircu |
LSI / Broadcom SAS2 and SAS3 HBAs and their OEM derivatives |
WD_SERV |
(native) | NVMe devices |
For the SAS_HBA group the choice between the SAS2 and SAS3 utility is made per card, not per appliance: each card is offered to sas2ircu first, and sas3ircu is used only for cards sas2ircu does not recognise. A card neither utility recognises is dropped from discovery.
Where a vendor utility needs coaxing -- an OEM-rebadged card that should be treated as a plain HBA rather than a RAID card, for instance -- the model-matching keys in qs_hwadapter.conf decide which plug-in claims it. Both that file and qs_enclosure_layout.conf are listed on QuantaStor Configuration Files, which explains where to put an edited copy so it survives a package upgrade. Do not edit the packaged copy in place.
Discovery runs on a timer rather than continuously. The loop interval is hw_alert_check_timeout_sec in the [hw_controller] section of /etc/quantastor.conf, which defaults to 120 seconds and is never allowed below that. Most passes only collect controller events; a full rediscovery of controllers, enclosures and disks happens on every seventh pass, so roughly every fourteen minutes at the default setting. That is why newly attached hardware can take some minutes to appear on its own, and why there is an explicit rescan.
qs hw-controller-rescan --controller=<controller> forces a discovery pass scoped to that card's plug-in; qs hw-controller-rescan-all covers every plug-in on the appliance. Adding --flags=force to the latter also clears the hardware-to-operating-system correlation cache and rescans physical disks, which is the option to reach for when a drive is showing up under the wrong bay or is not being tied to its Physical Disk.
HBAs and RAID controllers
The two card types are managed through the same objects but they are not interchangeable, and the choice is not a matter of taste.
Scale-up storage pools do not use hardware RAID. A QuantaStor scale-up pool is a ZFS pool, and ZFS must see the raw drives to do its job: it manages redundancy, detects and repairs silent corruption from its own checksums, and needs direct access to each device to do so. A RAID card in front of the drives hides them behind a logical volume, takes over the redundancy decision, and defeats the repair path. So for scale-up pools, use an HBA and present every drive individually. Configure the card in IT mode where the firmware offers a choice.
Hardware RAID has two legitimate roles:
- Boot devices. We recommend a setting up a software RAID1 mirror for boot in the text mode installer, or a boot card such as the Dell BOSS, to mirror the appliance's own operating-system drives.
- Scale-out configurations. Hardware RAID controller RAID units are not recommended for use with scale-up or scale-out storage. Some exceptions exist for large scale-out cluster designs.
QuantaStor records what a card can actually do as a capability set, and both the web interface and the service enforce it. A card claimed by the SAS_HBA plug-in reports only the JBOD capability, and as a result the following operations are rejected outright with "This operation is not supported with this vendor/model of hardware":
- create, grow or delete a RAID unit, and SSD cache create, enable or disable
- mark or unmark a hardware hot spare
- mark a disk good
- import foreign RAID units
- silence or clear controller alarms
The web interface hides rather than greys these. The right-click menu on a controller disk offers Create RAID Unit, Mark Hot-spare, Unmark Hot-spare and Mark Good only when the controller reports the create-unit capability, so on an HBA disk the menu is reduced to Identify..., Remove..., Modify Disk... and Properties.... On an HBA the only operations that reach the hardware are drive identify and rescan.
Controller properties and firmware
The Hardware Controllers grid shows the state, model, firmware and BIOS revisions and serial number of each card, grouped by appliance. qs hw-controller-get --controller=<controller> returns the full property list, including the SAS address, the Controller Group, the drive and unit counts, whether a battery backup unit is present, cache memory size, and the rebuild and verify rates on cards that report them. Controller and enclosure firmware revisions are reported for reference; QuantaStor does not check them against a known-bad list -- that applies to media firmware only, covered under Firmware version checking below.
Modify Hardware Controller sets two things and neither of them touches the card:
- Tag / Alternate Name -- a label of your own, useful when an appliance has several identical cards and the vendor-generated names are hard to tell apart.
- Description -- free text.
Enclosures, layouts and the slot map
An enclosure object is created for each chassis or expander a controller reports. Note that a single physical JBOD produces one enclosure object per path into it: in a highly-available configuration with two appliances and two HBAs each, the same chassis typically appears four times. The Chassis Tag field exists to reconcile that -- give every enclosure object belonging to the same physical box the same tag, and pool creation treats them as one fault domain when distributing drives across vdevs. Setting a chassis tag also propagates to other grid members that see the same enclosure SAS address.
An enclosure layout supplies the geometry QuantaStor needs to draw the chassis: how many rows and columns of bays, which traversal order maps a bay number to a grid position, which grid positions are occupied by a component rather than a drive, whether drives are mounted horizontally or vertically, how bays group into drawers, and which chassis photograph to display. The appliance ships 285 layouts across 16 vendor groups, in qs_enclosure_layout.conf.
Layouts are matched automatically. For an external JBOD, QuantaStor scores each candidate layout against the enclosure's reported vendor string, product string and bay count. For the appliance's own chassis, it matches against the server's manufacturer and product name as reported by the system firmware. A vendor match is required, a product match adds to the score, and an exact bay count adds most; the best score wins. A JBOD that matches nothing is left without a layout, and a server that matches nothing falls back to a generic layout named None whose description asks you to pick one. The generic fallback for a JBOD is named Default and is a three-row, four-column grid.
Two things follow from this that matter in practice. First, once you choose a layout by hand it is never overwritten by auto-detection again -- only an empty selection or one of the two generic fallbacks is eligible for automatic replacement. Second, matching uses vendor and product strings and the bay count, and nothing else; SAS address and chassis tag play no part.
The Enclosure Diagram
The diagram is a bay-by-bay picture of the selected appliance's enclosures. Each occupied bay is labelled with its drive's name and coloured by that drive's health; empty bays are drawn unfilled and labelled with their bay number. Hovering a bay gives a tooltip with the drive's name, vendor and model, serial number, size, bay, controller-reported status, temperature and device path -- which is the quickest route from a picture of a chassis to a device name. The magnifier buttons in the panel header zoom the diagram.
Colour in this view tracks drive health, not how the drive is being used: a pool member and an unused drive both draw green if they are healthy. The same underlying model drives a pool-oriented view where vdev membership and spare roles are distinguished; see Storage Pools.
Choosing a layout
Modify Hardware Enclosure is where a wrong or missing layout gets corrected. The dialog has:
- Hardware Controller and Hardware Enclosure -- which enclosure you are editing.
- Description and Tag / Alternate Name -- free text and a local label.
- Chassis Tag -- the physical-chassis grouping described above.
- Vendor Group -- narrows the layout list to one manufacturer.
- Enclosure Layouts -- the layout itself. Choosing one redraws the diagram immediately.
- Cage or Drawer Layout -- for chassis whose bays are split into drawers or cages that are described by child layouts. It is disabled and shows N/A when the selected layout has no children.
The Selected Enclosure Layout Information fieldset above the combo boxes previews the chosen layout: its Vendor, Model, Drive Bays count, and the chassis image. These are properties of the layout, not of the enclosure -- the fieldset heading says so, and it is worth reading carefully, because the Vendor and Model columns in the Hardware Enclosures grid currently show these same layout values rather than the enclosure's own. To see what the hardware actually reports for itself, use qs hw-enclosure-get --enclosure=<enclosure> or the object's Properties panel.
If no shipped layout fits your chassis, add your own to qs_enclosure_layout.conf; Adding Hardware Enclosure Layouts documents the file format. In a grid, update the file on every member.
The same fields are available from the CLI:
qs hw-enclosure-list qs hw-enclosure-layout-vendor-group-list qs hw-enclosure-layout-list qs hw-enclosure-modify --enclosure=<enclosure-id> --enclosure-layout="Supermicro Server SBB 2027B/2028R (2U24)" qs hw-enclosure-modify --enclosure=<enclosure-id> --chassis-tag=rack3-jbod1
Expanders and enclosures reporting zero bays
An enclosure object with 0 slots is normal and is not a fault. A SAS expander presents itself to the controller as an enclosure services device in its own right, so it becomes an enclosure object alongside the chassis whose bays it fronts. It has no bays of its own, and it is the object that carries the expander's real identity -- vendor, model, SAS address and expander firmware revision -- which is what you want when checking expander firmware or confirming cabling. The bays live on the sibling enclosure object.
Identifying a drive in the chassis
Identify Hardware Controller Disk Device flashes the drive's own activity or fault LED so you can find it in a rack. Select Blink Type offers four choices:
- On (the default) -- light the LED and leave it on until it is explicitly turned off.
- On Duration -- light it for a number of seconds, default 30, then turn it off automatically.
- Off -- turn it off now.
- All Slots Off -- turn identify off for every blinking bay on the controller.
Below that, Storage System and Hardware Controller scope the drive list, and the list itself is multi-select with a search box, a Reset button that clears the filter, and running totals of drives found and selected. Opening the dialog from a disk's context menu pre-filters it to that disk.
The equivalent command is qs hw-disk-identify --disk-list=<disks> --controller=<controller> --blink-type=on --duration=<seconds>. A duration of 0 means the LED stays on until it is turned off.
An empty bay has no drive LED to flash, so it is addressed through the enclosure instead. Identify... on an enclosure opens Identify Hardware Slot Device, with the same four blink types and a list of the enclosure's bays. That list is built from enclosure services data, so an enclosure whose expander does not provide usable SES element data has no bays to offer and the list is empty; see Enclosure services below. The CLI form is qs hw-enclosure-slot-identify --enclosure=<enclosure> --slot-list=<slots> --blink-type=on, which also accepts --all-slots.
Two constraints are worth knowing before you rely on an identify. Blink type On cannot be combined with all-bays, and blink type Off cannot be combined with a duration. And a timed identify occupies a worker thread for its whole duration, so prefer a short duration or an explicit off over a very long timer.
If the LED does not light, see When an enclosure or slot map is wrong -- both routes to the LED depend on data the controller or expander may not be providing.
Enclosure services (SES)
SCSI Enclosure Services is the in-band protocol by which an enclosure describes its own bays and lets a host drive their LEDs. QuantaStor talks to it directly through the sg_ses utility against the enclosure's /dev/sg* device; it does not use the kernel's /sys/class/enclosure representation, so an empty /sys/class/enclosure says nothing about whether QuantaStor's SES support is working.
What QuantaStor takes from SES is bay-level information: which bays exist, which are occupied, the SAS address of the drive in each, and each bay's identify-LED state. That is what makes the fast, vendor-neutral LED path and the empty-bay identify possible, and it is what populates the per-bay objects behind Identify Hardware Slot Device.
Two points that are easy to get wrong:
- SES is not where the fan, power-supply and temperature-sensor counts come from. Those numbers on an enclosure object are parsed out of the vendor utility's own enclosure table, and where the utility does not describe an enclosure at all they are placeholders rather than measurements. They are element counts, not health readings: there is no threshold, no state and no alert behind them. Server-level thermal and power health is a separate mechanism driven over IPMI, and it does raise alerts -- see Alert Manager and Performance Monitoring. Per-drive temperature is reported separately, on the Hardware Disk object and in the enclosure-diagram tooltip.
- Not every expander implements enough of SES to be useful. An enclosure must expose the element descriptor pages before any of the above works. Older expanders sometimes advertise only the Short Enclosure Status page, which conveys a single overall status byte and no element data at all. On such hardware there are no bay objects, no SES LED path, and no empty-bay identify, and QuantaStor falls back to the vendor utility for drive LEDs. You can check what an enclosure supports directly:
sg_ses --page=sdp /dev/sg1
A usable enclosure lists Configuration, Enclosure Status and Element Descriptor pages among the supported diagnostic pages. One that lists only Supported Diagnostic Pages and Short Enclosure Status cannot provide bay data, and sg_ses -j against it fails with "Enclosure only supports Short Enclosure Status".
QuantaStor also backs off from an enclosure that keeps returning unusable SES data, skipping it after repeated failures rather than retrying indefinitely and filling the log.
Hardware hot spares
A hardware hot spare is a drive handed to a RAID controller so the controller can rebuild a degraded RAID unit into it without any involvement from QuantaStor. It applies only where a pool is built on hardware RAID units, because that is the level at which the repair happens. Mark one or more drives as spares and a controller with a degraded unit will consume a spare and start rebuilding on its own.
The CLI forms are qs hw-disk-mark-spare --disk-list=<disks> --controller=<controller> and qs hw-disk-unmark-spare. Spares created this way are global to the controller, not dedicated to a particular RAID unit.
On an HBA there is no such thing. There are no RAID units for a spare to protect, the menu items are not offered, and the commands are rejected. Spares for a scale-up pool are a ZFS concept managed at the pool level instead -- see Storage Pools and Physical Disks/Devices.
Firmware version checking
QuantaStor ships a small blocklist of media firmware revisions known to cause problems, in qs_firmware_check.conf. Each entry names a vendor, a model fragment, one or more firmware revisions and the message to raise. A drive matching an entry produces an alert carrying that message, which reaches the same destinations as any other alert -- see Alert Manager.
Three characteristics of this check are worth knowing:
- It covers drive firmware only. Controller and enclosure firmware revisions are reported but not checked.
- Vendor must match exactly; model and firmware revision are matched as case-insensitive substrings.
- The check runs at service start. A drive hot-added later is not checked against the list until the service restarts or a System Health report is generated, so a firmware alert appearing at boot may relate to a drive installed some time earlier.
The file is listed on QuantaStor Configuration Files and can be extended with your own entries; the shipped copy contains a commented example alongside the live rule.
Hardware RAID units
On a RAID controller, a logical drive is modelled as a Hardware RAID Unit. QuantaStor can create, grow, delete, encrypt and identify units, and manage controller SSD caching, from the web interface, the CLI and the REST API. These controls appear only for cards that report the corresponding capability.
- Creating units. Select the drives and the RAID level. See Hardware Controller Create RAID Unit. Create Pass-thru Units presents drives individually through a RAID card that will not otherwise expose them raw.
- Importing units. Drives moved from another controller, or attached to a controller that was booted while their enclosure was powered off, are usually treated by the card as a foreign configuration and do not appear until they are explicitly imported. Import RAID Units does that; see Hardware Controller Import RAID Units.
- Deleting units. Delete RAID Unit destroys the logical drive and the data on it.
- Silencing alarms. Most RAID cards have an audible alarm. In a data centre nobody hears it, so we recommend turning it off; Silence Alarm does this per controller, and Clear Events clears the recorded controller events. See Hardware Controller Silence Alarm. Note that silencing is available from the web interface and the API but has no
qscommand;qs hw-alarm-clear-allclears events rather than silencing the buzzer. - SED / FDE security keys. On controllers that support self-encrypting drives, a controller security key can be created and later changed. This is supported on LSI/Broadcom MegaRAID and Dell PERC controllers only.
Controller SSD caching
Adaptec and LSI/Broadcom controllers offer an SSD caching tier in front of their RAID units, and QuantaStor detects and manages it where the card reports it. The cache unit is created from SSDs and then enabled against individual RAID units. Created as RAID0 it is a read cache; created as RAID1 or RAID10 it caches reads and writes.
This works alongside, rather than instead of, the card's NVRAM write-back cache: NVRAM is typically 1 GB to 4 GB, while an SSD tier can extend the cache to a terabyte or more. How much it helps depends heavily on the workload and on the drives chosen.
Only enterprise or data-centre grade SSDs are supported for this, and for write caching we require high-endurance devices rated at 10 DWPD or better. Desktop-grade SSDs are not designed for sustained load, give unstable performance, and are not supported. Not every SSD model is accepted by the controller vendors for their caching technology either -- if a cache unit cannot be created, check the card vendor's compatibility list. If the caching options do not appear at all, confirm with the card vendor that the feature is licensed and enabled on your controller.
When an enclosure or slot map is wrong
This is the most common problem in this area, and the symptoms are recognisable.
The diagram does not look like the chassis
Too many bays, too few, or bays in the wrong arrangement means the wrong enclosure layout is applied. Correct it with Modify Enclosure... as described in Choosing a layout. If nothing in the list matches, add a layout -- see Adding Hardware Enclosure Layouts.
Remember that a layout is cosmetic geometry. Selecting one changes what is drawn; it does not change which bay the controller reports a drive in.
The controller and enclosure are in a Warning state about correlation
A controller whose state detail reads "Output from vendor utility for this controller does not provide adequate information for proper device enclosure/slot correlation", paired with an enclosure reading "Output from vendor utility does not provide adequate information for proper device enclosure/slot correlation", is telling you something specific and important: the bay numbers shown for that enclosure are not physical bay positions.
This happens when the vendor utility reports drives against an enclosure number it does not then describe. QuantaStor cannot leave the drives unplaced, so it synthesises a stand-in enclosure, moves the drives onto it, and numbers them 1 to N in discovery order. The bay count on such an enclosure is therefore just the number of drives re-homed onto it, and the fan and power-supply counts are placeholders.
You can confirm this directly from the vendor utility. On an LSI SAS HBA:
sudo /opt/osnexus/quantastor/raid-tools/sas2ircu 0 display
If every Device is a Hard disk block reports the same Enclosure # and Slot # -- commonly 0 and 0 for all of them -- and the trailing Enclosure information table has no entry for that enclosure number, then the utility is not providing correlation data and the synthesised numbering is the expected result.
The practical consequences:
- Do not use the displayed bay number to decide which drive to pull. Identify the drive by serial number instead. The serial is on the Hardware Disk object, in the enclosure-diagram tooltip, and printed on the drive carrier.
- Drive identify may not work. With no usable SES data, the LED request goes to the vendor utility addressed by the synthesised bay number, and the utility rejects a bay it does not know about. Confirm before trusting an identify: run it, then check whether the LED is actually lit rather than relying on the operation reporting success.
- Enclosure-level bay identify is unavailable, because the synthesised enclosure has no SAS address to resolve to an SES device.
There is no configuration fix for this; it is a limitation of what the card's firmware and utility report. Where reliable bay mapping matters, use a card and enclosure combination that provides full SES element data, and check with sg_ses --page=sdp as described under Enclosure services.
An enclosure or disk is gone but still listed
When hardware is removed, its object is marked Missing rather than deleted, so that a disk belonging to a pool or an OSD is not silently forgotten. Once you have confirmed the hardware is genuinely gone for good, clear the stale entries:
Or from the CLI, optionally narrowed to one appliance or controller:
qs hw-disk-clear-missing --storage-system=<system> --controller=<controller> qs hw-enclosure-clear-missing --storage-system=<system> --controller=<controller>
Both are database-only operations that remove objects in the Missing state and nothing else; if there is nothing marked missing they report that and do nothing. Neither touches the hardware, and neither can remove an object for hardware that is still present.
To flag a physically failing drive for removal, qs hw-disk-delete --disk-list=<disks> --controller=<controller> marks it so it can be pulled from the enclosure. On an HBA this succeeds only for entries already in the Missing state.
Vendor-specific triage
Some controller families have extra maintenance utilities -- clearing a foreign configuration, forcing write-back cache mode, scrubbing a disk control block left behind by an old RAID card. Those are collected on HBA/RAID Utilities.
CLI reference
| Command | Purpose |
|---|---|
qs hw-controller-list |
List discovered controllers |
qs hw-controller-get |
Full property list for one controller |
qs hw-controller-rescan |
Rediscover one controller |
qs hw-controller-rescan-all |
Rediscover all controllers; --flags=force also re-correlates disks
|
qs hw-controller-import-units |
Import a foreign RAID configuration |
qs hw-enclosure-list |
List enclosures with bay counts and SAS addresses |
qs hw-enclosure-get |
Full property list for one enclosure |
qs hw-enclosure-modify |
Set layout, chassis tag, label or description |
qs hw-enclosure-layout-list |
List available chassis layouts |
qs hw-enclosure-layout-vendor-group-list |
List layout vendor groups |
qs hw-enclosure-slot-identify |
Blink one or more bays, including empty ones |
qs hw-enclosure-clear-missing |
Remove enclosure objects marked Missing |
qs hw-disk-list |
List drives as the controller sees them |
qs hw-disk-get |
Full property list for one drive, including its SMART verdict |
qs hw-disk-identify |
Blink a drive's LED |
qs hw-disk-mark-spare |
Mark a controller hot spare (RAID controllers only) |
qs hw-disk-unmark-spare |
Clear a controller hot spare |
qs hw-disk-mark-good |
Return a drive the controller marked bad to a good state |
qs hw-disk-delete |
Mark a drive for removal from the enclosure |
qs hw-disk-clear-missing |
Remove drive objects marked Missing |
qs hw-unit-list |
List hardware RAID units |
qs hw-unit-create |
Create a hardware RAID unit |
qs hw-unit-identify |
Blink every drive in a RAID unit |
qs hw-alarm-list |
List controller events |
qs hw-alarm-clear-all |
Clear recorded controller events |
Controllers, enclosures, disks and units each also have a search form taking --search-filter -- qs hw-controller-search, qs hw-enclosure-search, qs hw-disk-search and qs hw-unit-search. qs encl-render-get returns the computed model behind the enclosure diagram, including per-bay role and group information; note that its output labels bay health using the general object-state names, so read the numeric role and the underlying qs hw-disk-get state rather than that label.
Related pages
- Physical Disks/Devices -- the operating system's view of the same drives
- Multipath Configuration -- multiple paths to a shared SAS enclosure
- Storage Pools -- pool layout, enclosure redundancy and pool-level spares
- Adding Hardware Enclosure Layouts -- adding a chassis layout
- HBA/RAID Utilities -- vendor-specific maintenance tools
- QuantaStor Configuration Files -- where the hardware configuration files live
- Performance Monitoring -- sensor and temperature reporting
- Alert Manager -- where hardware alerts go
- Hardware Controller Create RAID Unit, Hardware Controller Import RAID Units, Hardware Controller Silence Alarm, Hardware Enclosure Modify, Hardware Disk Identify, Hardware Disk Mark Hotspare, Hardware Disk Mark Good, Hardware Controller Rescan
Verified against QuantaStor 6.9.0.