Computer data storage - RAID - OMSA notes

From Helpful
Jump to navigation Jump to search
Computer data storage
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


Installing in RHEL/yum

⌛ This hasn't been updated for a while, so could be outdated (particularly if it's about something that evolves constantly, such as software or research).

Dell have a script you can download and run that adds their repository to yum. See e.g. http://linux.dell.com/repo/hardware/

After this, something like yum install srvadmin-all should install everything you want.

If you want to downgrade, you'll want to

  • uninstall any configured version (which involves some manual removal of various parts),
  • clear existing yum knowledge about OMSA: Before running the appropriate Dell bootstrap script, remove the repository in /etc/yum.repos.d (probably called something like dell-omsa-repository.repo), and do a yum clear all.
  • Install as usual


If you want to avoid upgrades because of the segfault problem, you'll can tweak yum.conf to add something like exclude=srvadmin-*



Using

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


CLI

If restricted to the CLI, you probably want to find the PDF named something like Dell OpenManage Server Administrator Version Command Line Interface Guide


Checking

List/overview of arrays:

omreport storage vdisk


List physical disks:

omreport storage pdisk controller=0
# shorter summary with:
omreport storage pdisk controller=0 | egrep "^ID |Status|State|Failure"


There is also:

omreport system alertlog


Scrubbing

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.
omconfig storage vdisk action=checkconsistency controller=0 vdisk=0 

Seems to be a foreground thing, so run in screen/tmux or from cron


Replacing a disk

Inspecting SMART

These controllers are supported in smartmontools since 5.39, via -d megaraid (which it will probably rewrite as -d sat+megaraid).


Find the controller device

For example:

# smartctl -i /dev/sda
smartctl 6.1 2013-03-16 r3800 [x86_64-linux-2.6.18-274.18.1.el5] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               Dell
Product:              Virtual Disk
Revision:             1028
User Capacity:        146,163,105,792 bytes [146 GB]
Logical block size:   512 bytes
Logical Unit id:      0x600508e00000000095b64cca51b2cf02
Device type:          disk
Local Time is:        Fri Oct 25 14:16:12 2013 CEST
SMART support is:     Unavailable - device lacks SMART capability. 


# smartctl -i /dev/sdb
smartctl 6.1 2013-03-16 r3800 [x86_64-linux-2.6.18-274.18.1.el5] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

Smartctl open device: /dev/sdb failed: DELL or MegaRaid controller, please try adding '-d megaraid,N'

sdb it is.


Find the right indices to query

The indices the drives are on may well be offset. If you try ,0 and get:

Smartctl open device: /dev/sdb [megaraid_disk_0] failed: INQUIRY failed

...don't be discouraged. Keep trying and see what indices respond - possibly like:

for num in $(seq 0 255); do echo "Trying "$num; smartctl -i -d megaraid,$num /dev/sdb; done > indexscan

In my case the drives were on indices 33 through 48. Go figure.


Segfaults

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

(from web searches and personal experience)


I got consistent segfaults on one host (in omcliproxy and everything that wraps it, which seems to be most things), which renders both OMSA's CLI interface and web service useless.


It turned out to be related to there being a configured tun interface. It's related to interface behaviour/type, not name. It looks like OMSA assumes all interface are Ethernet type, and fail on almost anything else, including things like tun and ppp (but not tap, because their point is acting like Ethernet).


This problem seems to go back to at least OMSA 6.1 (2009), but seems to not have been fixed in recent versions (7.2.1, current in 2013; see version history),


It seems like Dell doesn't consider this OMSA-linux incompatability (even though non-Ethernet interfaces have always existed) but an unsupported-third-party-software problem, probably because report-wise, most people run into this when they add VPN or such. Sigh.


Suggestions:

  • Dell have half a workaround which lets you use the command line interface, but doesn't fix the web interface (see support link below)
  • Downgrade OMSA to 5.5?(verify) (May be too old to work for you, or for it to fit in your system's dependencies)


See also:

See also