MDS9000: Setting summer time for CET

After rebuilding two MDS9148, I wanted them to correctly switch the summer/winter time for my time zone. Currently I’m in CET (or CEST during the summer), so I googled for that. The search came up with Cisco-FAQ, however that needed a slight adjustment.

Apparently the NXOS doesn’t support the feature “recurring” in the clock configuration. So I had to slightly adapt the configuration line:

vCenter: Removing VSC custom attributes

Well, yesterday I got pissed of those Virtual Storage Console custom attributes.

Currently we don’t use the Provisioning & Cloning feature of the VSC, thus we don’t need the custom attributes. After poking around, I decided to write a short PowerCLI script to do the task.

It’s really rather simple, so here goes:

NetApp: Changing DS4243 shelf ID

I’m working on a project right now, providing a SnapVault target for our “big” NetApp. So we moved our 3240 to it’s target location, I spent most of my time yesterday doing the cabling (SAS and ACP, as well as power).

I’m still not finished, I still need to “beautify” the power cables, need to fix the network cables (currently I don’t have none ….) and some other minor stuff. But lemme skip back a bit.

The 3240 initially had only two shelfs, one with the ID 10 and the other with the ID 50. When reimplementing the thing, I wanted to do two things:

  1. Make the shelfs “proper” (i.e. adjacent shelf IDs)
  2. Make sure it’s done right
So, I ended up googling the topic (or rather NetApping, since the NOW page isn’t being indexed), and found a NetApp Community post. As I already did a complete wipe/cleanconfig of both filers, I was left with this:
  1. Halt both controllers (don’t power them off!)
  2. Change the shelf ID using the front panel of the DS4243
  3. Power-cycle each shelf
  4. Wait at least 30 seconds
  5. Boot both controllers
And that actually did it, my HA controllers are up and running, with the new shelf ID’s.

NetApp: Migrating FCP luns with ndmpcopy to another controller

Well, I’m in a situation, where I need to move all volumes from one controller to two others. So I looked at the ways I had available:

  1. Freshly implementing everything: No option at all!
  2. vol copy: Is rather slow, thus no option
  3. ndmpcopy: That’s exactly what I needed!

ndmpcopy is a great way to copy over a whole volume including it’s files (thus FCP luns) to another volume/controller.

First I threw in a crossover cable, since at around 6 PM our backup system starts it’s daily run, and everything else running via IP in between 6 PM and 6 AM is seriously impaired by this. Configured the additional ports on all three controllers (picked a private, not-routed range just in case) and then kicked of a simple bash script that ran the following:

Now, that in itself worked like a charm as you can see from the output below.

However, once I switched the UCS into the correct VSAN and modified the Boot Policy, the XenServer would boot, but didn’t find *any* Storage Repository. So I went ahead and looked at the CLI of the XenServer, looked at /var/log/messages and saw that apparently the PBD’s weren’t there yet (for whatever reason).

Poked around in /dev/disk/by-id, looked at the output of xe pbd-list and found that the SCSI-IDs used in the PBD’s we’re actually not present yet. So I was like *wtf* for a moment, however then took a quick peek at the output of lun show -v /vol/vol_xen_boot on both NetApp controllers and found the cause for my troubles:

As you can see, the lun itself is available and mapped with the correct LUN ID. However, if you look closely at the serial of both LUNs you might notice what I noticed. So it turns out, ndmpcopy does the copy-process, however you need to adjust the LUN serial on the destination controller to match the one from the source controller, otherwise it’ll throw any system out of whack.

After adjusting that, everything came up just fine. And I’m finished with my first XenServer environment, only the big one is still copying.