SnapManager for SQL Server: Service fails to respond in a timely fashin

Well, we recently upgraded the SnapManager version on our test box to 6.4.1. Now however, after restarting the box the SnapManager service failed to start … The error was something like this:

SnapManager: Failed to start

Now, first I stumbled upon this NetApp Community post, which only contained the “solution” to increase the global! wait time for services. That didn’t sit well with me.

So after looking through NOW! for a bit, I actually found the correct way. The fix is described in KB2010835. Yet again, another certificate error. Why do vendors deploy SSL certificates, when they use untrusted ones, which defeats the purpose of SSL certs or at least “brings up” users to ignore any error message they get concerning SSL certificates ?

As the KB article describes, you need to remove the following settings:

SnapManager for SQL Server: Internet Explorer fixes
SnapManager for SQL Server: Internet Explorer fixes

Installserver: Regenerate PXE base menu

Well, here’s the promised script to regenerate the main PXE menu based on the menu entries created by register-suse and register-vmware.

Installserver: Publish a VMware ESX ISO – register-vmware

Here’s an old script, that also uses the magic provided by pxe-menu-generation (the script I posted before), but for VMware ESX/ESXi.

Installserver: Publish a SLES/OpenSUSE ISO – register-suse

Well, I’ve been tinkering with a way to “unify” the way we deploy new OpenSUSE/SLES ISOs onto our installation server, once they are released. So here, I’ll show you the script I came up with:

This also needs a second script, as this will only create a menu entry, not the menu itself. You’ll find the script in the next post!

VMs in Alarm state after scheduled maintainance

Well, I’m back at work after three weeks of vacation (some pictures to follow) and the provider hosting our disaster datacenter had their annual (or is it monthly now?) SAN maintainance, so we shut down everything over there by 9:00 am.

After things were back up around 5pm, I booted the ESX hosts, however the VMs we’re all displaying the alert state – as if either the VMs had an HA event or we’re using to much CPU time. It didn’t matter whether or not the VM was running or not, the state persisted.

vCenter - VM in alarm state
vCenter – VM in alarm state

Lucky me, someone else already ran into this issue. So, after simply vMotion’ing the VMs to another host and the VM would no longer be in that alert state.

NetApp – Remove LUN mappings

As promised in the earlier post, for completeness sake, here’s the counterpart for removing the LUNs in the first place.

With that, you can simply run it against a NetApp controller and remove every LUN map except the one with LUN ID 0 (which is pretty handy when installing/reinstalling ESX servers).

NetApp – Copy LUN mappings

Well, today I had another idea (basically like the one I wrote for SVC’s VDisk mappings a while back) for a script:

I’ll post the counterpart of the script (to remove the LUNs) in a second post later on.

NetApp – Get a list of volumes containing too much LUNs

Well, after figuring things out (and realizing that if you create a LUN in the same size as the volume it’ll break), I decided to write yet another script to figure out which LUNs needed fixing.

And with that you have a list of volumes, with the amount of space they need to resized in order to accomodate the contained LUNs and the snapshots.

NetApp – Get a list of all volumes not being used

Well, I had another task for today … I have an amount of FlexVolumes (sixty currently per controller), and I didn’t know if we had any, that didn’t have any LUNs on them. Now I thought there was a command for that since my co-worker mentioned something like that. However, once again … there isn’t.