SAN reporting

We do have some customers, who get charged on a monthly basis for their SAN usage. We already had “reporting” in place, but that wasn’t very flexible. So I went ahead and rewrote the current reporting script from scratch, and this is what I’ve come up with:

I gotta say, once again I learned a lot … two new things about awk!

I know the report itself doesn’t look *that* pretty, but it serves a purpose!

me + flying = chaos!

It’s been one of these days (yeah, I know … AGAIN). I was scheduled to depart from Stuttgart (STR) to Rostock – Laage (RLG) on 16:45 on Sunday. Well, if you know me, I did actually miss that flight the check-in for that flight by 15 minutes. 15 FUCKING minutes! Immediately called my Taxi (that is my parents) and told them to turn around, since they already had left to collect me from the airport ..

I walked back outside, through the revolving door, and while inside the door decided to get back to the ticketing counter. I ended up booking another flight (paying another 30€ for the chanced flight), and landed three hours later in Berlin Tegel (TXL). Thanks to my parents (who collected me from Tegel, and spared me the three hour train travel — like I did back in February), I was finally home around 1:00 AM the next day …

But guess what, another lesson(s) learnt!

Displaying Windows Architecture with bginfo

On all our servers in the basement, we do have bginfo installed, in order to quickly get certain information. Now as I was struggling with a big Service Pack roll out, I looked into making bginfo also display the OS architecture. But apparently it isn’t that easy … At least bginfo doesn’t provide it by default.

After (yet another hour in front of Google), I finally found what I was looking for. At first I didn’t limit the query on a specific CPU, but that turned out to be shitty (x32 being displayed twice, once for each CPU). But after limiting it to DeviceID=’CPU0′ it works like a charm 😉

Vuvuzela’s should be banned!

It’s just past the first game of our national team, and the vuvuzela’s are actually getting on my nerves. It’s not really the vuvuzela’s per se, it’s just this one kid running around with it all day long. At first I was like “wtf kind of animal is this ?” Until I saw him running around with this weird instrument …

Vuvuzela

SLES10 not installing boot loader in MBR

Well, as I mentioned in my earlier post, I had some trouble during the week. I was having issues with SLES10 installations not finishing during the bootloader installation phase. After trying out different flavors (as in 10SP2 x64/x86, …), and not having any luck with this, I went searching on Google as a last effort try. Guess what, yet again Google helped me out!

It was pretty simple. Putting /dev/cciss/c0d0 into /boot/grub/device.map as (hd0) made the grub-installer finish. Now, figuring out how to transfer those information during the installation proved difficult. I was just about to give up, while reading through the AutoYAST documentation, when it struck me. There is even an extra chapter for this stuff, so simply putting the following into my profile solved my issues:

distributions.barfoo.org going away

Since I didn’t have any time to actually maintain my own repository of RPMs, as well as I don’t have any need for the RPMs contained within (simply I don’t use them at work anymore), the whole shebang is going away!

I know a few people actually still use it, so I’m gonna put in a disclaimer and let some time pass before completely removing it. Just be warned, it’s going away! Again:

distributions.barfoo.org is going away!

Reset Master Boot Record (MBR)

Since I’ve been playing with my AutoYAST setup for the last few days, working out the kinks (for example SLES10 not being able to install into the MBR), I needed a way to zap the MBR (as in remove grub to see whether or not the installation would install a new loader). So after quickly googling, I found this:

That actually does the trick. The loader as well as the partition table are gone after wards!

VMware Consolidated Backup and TRANSPORT_MODE=”hotadd”

As the title says, I’ve been playing with vCB (inside a VM) and the TSM integration with newer (>6.0) clients for work. Result of all this work should be a feasibility study. We’re currently thinking about replacing our VMware server(s) with ESXi. But as most of you know, if you install ESXi, you simply can’t install anything (well, you can .. on ~100KB of disk space, which is compared to a TSM client weighing roughly 120MB nothing!). As we would like the possibility to backup VMs on image-level, I went looking at solutions.

  1. VMware Data Recovery
  2. VMware Consolidated Backup
  3. vRanger, ……

As I was looking for something that wouldn’t cost us any money (thus excluding the third), I took a look at vDR and vCB. One point I do have to give to vDR is, that it’s damn fast. Only bad thing about vDR is that it doesn’t integrate at all with TSM, and it ain’t supported to install a TSM client inside the vDR VM. So vDR was also done for.

Only remaining thing was vCB. I remember way back when TSM didn’t support vCB directly, at which time it was *quite* the hassle to configure. But with newer TSM clients (as in the newer 6.x ones), IBM decided to integrate support for it. Which makes setting things up quite easy. You may think at least.

Since I wanted to use “hotadd” as transport mode for the vmdk’s (which is basically creating a snapshot of the vmdk and assigning that snapshot to the vCB VM), I did have to tinker around with some JavaScript files in %ProgramFiles%VMwareVMware Consolidated Backup. Sure, it isn’t supported by VMware (which is a bit lame since they announced the EOL for vCB with the upcoming vSphere version), but I didn’t want to open a support request. I’m lazy, yep:

Change DEFAULT_TRANSPORT_MODE in utils.js from “san” to “hotadd“. But apparently this only solved the backup method for vmdk-level, but not for file-level backups. The file-level is still gonna use nbd (network block device), which kinda sucks since the backup is going out via network.

After doing that, the hotadd mode is still gonna fail, since apparently the denoted “VMware Consolidated Backup User” (vcb-user in my case) also needs permissions onto the datastore. The permissions the handbook sets for the user are okay, you just need to apply that role to your datastore(s) containing the VMs you want to backup too! Otherwise vcbMounter is gonna fail with a rather cryptic error telling you that it doesn’t have sufficient rights to create a linked clone.

Windows Server 2003: taskmgr giving “Logon failure”

I had myself a lot of fun today. I ended up patching a Windows Server 2003 x64 SP1, where the Task Manager wouldn’t start anymore. It simply failed (or in case of right clicking on the task bar wouldn’t even appear), so I went downstairs and pulled a hard disk out of the RAID1 array, just to be sure.

Really weird Windows errorI went ahead, installed SP2 (as you can see on the above picture) while having the jitters. Also installed the VirusScan I was scheduled to install, and the system came back online. Phewww.

After my maintenance window was over, I looked into this issue a bit deeper. First tried copying over a taskmgr.exe (both 32bit and 64bit) from another Windows Server 2003 x64 SP2 system with no luck. The next step, was looking at PATH. As it turns out it has something to do with that ….

As you can see, after fixing up the PATH environment variable, it works apparently .. Weirdly though, this issue doesn’t come up on another (identical) system, same PATH modifications, main difference: calling taskmgr.exe from the Run dialog works .. while it doesn’t on this particular system.

*Shrug* Gonna have to talk to my SAP guys tomorrow … 🙂