Been a while guys but rest assured I’ve been playing around with stuff and will be posting more soon. One of the bigger tasks I’ve completed recently is upgrading my home environment to vSphere 6. I have a Dell 2950 III with an MD1000 attached w/ ~11.2TB (RAID50) as a backup location that I recently moved to ESXi 6.0 and now that Dell has released OpenManage Server Administrator (OMSA) for vSphere 6 I figured why not try it out. OMSA is not new to me, but I know a lot of people have asked if it’s working in vSphere 6 yet and whether it’s reliable. This is an overview.
How does it work? : : What does it do?
If you’re familiar with Dell PowerEdge servers then you’re probably also familiar with iDRAC and chassis management (CMC). An iDRAC module is either a proprietary daughter card or embedded module that sits within the physical Dell server. It provides a small embedded webserver that you can log into remotely and gain access to critical system information (as well as gain access to the servers remote console should you need out-of-band access to the physical asset). The information the iDRAC/CMC can usually provide is limited to power status, temperatures, fan speed/status, power consumption, high-level information about the CPU/memory configuration, and not a whole bunch more.
There are a lot of aspects of a physical server that you can only access at boot – specifically RAID configuration and iDRAC setup (though later Dell Rx10 and later models can set the iDRAC IP through the LCD). There’s also a lot of hardware within the server that has advanced configuration status that isn’t presented within iDRAC and ordinarily you’d have to reboot and enter the BIOS to view/change it. This is where Dell OMSA comes in.
Dell OMSA is software that ordinarily runs within whatever operating system is installed on the server (usually Windows or Linux) and provides you more insight to your hardware without going through BIOS/etc. OMSA runs as an agent that listens on a port to a management console connection and basically brokers the connection between the managing console and the baseboard management controller (BMC). In plan speak, its software that lets you get to the hardware inside the server. Ok, simple enough. But what if you’re running ESXi on the server?
So, when you run ESXi on the server you have two options – settle for iDRAC/CMC access and only make configuration changes through iDRAC and reboot otherwise, or install Dell OMSA to run on the ESXi host itself and allow remote connections (in-band) from a remote console.
iDRAC vs. OMSA – what’s the difference?
I am sure there’s a spreadsheet out there that quantifies the differences in manageable attributes from iDRAC vs. OMSA, but rather than do that, here are screenshots of each:
Dell OMSA 8.1.0:
So, there’s clearly a lot more visible in the screenshot for OMSA, right? Sure, iDRAC 5 is antiquated and iDRAC 6 and now iDRAC 7 offer more insight, but you get the idea. One thing you’ll notice is that we can see the storage devices (PERC 6/i and 6/E) in OMSA and have no tab for that what so ever in iDRAC. This is, honestly, one of the biggest perks of running OMSA especially on a standalone ESXi host with direct attached storage (DAS). If it weren’t for OMSA, I may have an alert or warning on my storage enclosure and have no idea what the issue is. But, with OMSA, I can connect to the host via OMSA and see that the battery is failed (yes, most errors will show on the LCD, but…), the RAID is degraded, or any other issue. And, not only can I see the issue, I can remedy it if need be. For instance, you have the ability to completely manipulate the storage configuration without booting into the BIOS configuration for the controller:
Another thing you may have noticed is that the OMSA interface is not from 1980 like the iDRAC 5 appears to be. That’s because OMSA is developed to keep older BMC’s in mind and while the iDRAC 5 module is physical hardware that runs the webserver within a PowerEdge server, the OMSA software hooks into the BMC and otherwise runs within Windows (in this example). So, since OMSA is maintained and (so far) backward compatible to legacy servers, the interface evolves well beyond what it would have looked like in 2008 – 2010.
As I said, this is super handy if you have hosts with DAS. If you have a SAN then you already have the ability to configure the storage and create LUNs and all from that management interface. One thing you’ll notice when comparing the iDRAC and OMSA screenshots is the URL difference. One is pointed at the iDRAC DNS record (conwayesx2drac) while the other is going to my terminal server (conwayts1). The reason for this is because with OMSA you load the management console from a server/workstation with it installed – it is necessary to install the OMSA software some place that you will manage the server from. Once you launch Server Administrator you will be prompted with a hostname/IP, user, and password box. Since this is an ESXi box being managed, we enter the root username and password.
Installing OMSA within ESXi 6.0 GA
In order to get started using OMSA with ESXi 6.0 you’ll need the following:
- Dell OpenManageServer Administrator vSphere Installation Bundle (VIB) for ESXi 6.0, v8.1
- Dell OpenManage Server Administrator Managed Node(windows – 64 bit) v.8.1 OR
- Dell OpenManage Server Administrator Managed Node (Windows – 32 bit),v8.1
- WinSCP or some other method for transferring files to your ESXi host and Putty in order to connect via SSH
There are other ways of getting files to the ESXi host using VI Remote CLI (esxcli for Windows), etc. but in this tutorial I am using WinSCP and Putty for simplicity.
Once you have all of these items downloaded it’s quite simple to get it going.
- Install the Dell OpenManage Server Administrator Managed Node on any server you wish to manage OMSA from. It’s misleading that it’s called “Managed Node” because it sounds as if the installer goes on the node managed. Well, it can – if it’s a Windows server. Manging a node only works on a Dell server running Windows (and with a compatible BMC), though. And, if your server/computer you install the managed node on isn’t a Dell with a recognized BMC, then it just installs the OMSA software as a management console. So, grab the 64-bit or 32-bit installer, run it from the computer you wish to manage from, and move on to the next step.
- The Dell OMSA vSphere Installation Bundle (VIB) is going to come down as a ZIP file. It’s intuitive to unzip the file and use the contents within, and, technically you can. But, it’s just easier to plop the whole ZIP file over to the host using WinSCP with SSH enabled on the host:
- Login to you ESXi host using its hostname (or IP), root as user, and your root password and select SCP for the File Protocol:
- Once connected, copy the ZIP (or VIB file if you want) to /var/log/vmware. Note: I usually like to drop installation stuff in /tmp but when doing this and running the installation command ESXi threw an error. Dell recommends placing the ZIP and or VIB in /var/log/vmware and I guess it’s for this reason.
- All that is left is to SSH into the host and run the installation command. So, open up Putty and connect to the the hostname or IP and provide the root username and password:
- Finally, just enter the following installation command: esxcli software vib install -d /var/log/vmware/OM-SrvAdmin-Dell-Web-8.1.0-1518.VIB-ES
X60i_A00.zip which will yield a successful output (mine skipped because it’s already installed):
And, you’re done! Not hard right? It’s good to learn basic esxcli commands also, but most people will hardly ever be in the host installing VIBs so it’s not something you use too frequently. Once installed, there is no need to restart the host or anything. You can simply hop on over to your OMSA management console and launch Server Administrator, and connect to the host:
That’s all there is to it. Notice at the bottom of the OMSA login page there’s a link for “Manage Web Server” – you can switch between managing the local physical Dell server (if it is one) and a remote node. Pretty clever! Now, if you create a new virtual disk in your RAID controller or blow out the configuration and create a RAID5/6/10/50/60 and want to know if the background initialization is complete… you can! You can also delete the configuration and create a new one all within OMSA while ESXi stays up! Pretty slick, honestly.
Hope you guys find this useful. Oh, and as far as reliability… I’ve been running this for about 4 weeks without a hitch. The OMSA agent has had no hiccups or hangups, no host issues, etc. I do know that some people are super concerned about running the OMSA agent on production boxes because it could hang and cause issues, but I have yet to experience that. Granted, most ESXi hosts will have SAN storage and this is not as critical, but for those that don’t, this is very useful. And don’t think that OMSA is only good for storage configuration – it does much more, it’s just that I find myself in the storage side of things more often!