Enabling multipathing in autoyast installations

As I mentioned before, we’re starting to utilize Boot-from-SAN as a means to strip the blades of their local disk. As the title says, after trying a manual installation of SLES 11.1 via CD/HTTP I wanted to automate the process, in order to get a reproducible, consistent installation method. As you might have figured, AutoYaST doesn’t have any built in support for configuring multipathing (hey, that’s what Novell says here). Now, they also provide a comprehensive how-to on how to “add” this to your AutoYaST, using a DUD (or Driver Update Disk).

Now, you can download the provided Driver Update Disk to any Linux box and unpack it using cpio. As the KB states, do the following:

And you might get the same as I do:

Now, after creating the path in question (just mkdir -p /NETSTORE/Installsource/SLES11SP1-x86_64) and retrying the cpio, you’ll get the following:

Next, according to the KB article is moving the linux directory to your actual install location (in my case /srv/instsrc/sles/11.1/x64) and then booting your system in question. And guess what you get ? Nil (as in the setup starts, but /sbin/multipath isn’t being called — which is nothing in my setup).

Next I tried copying the cpio-image (/tmp/multipath.DUD) to my install location as driverupdate (I know the SLES setup is pulling that file), which produced a warning about an unsigned driverupdate file (as it isn’t in ./content) — which can be circumvented by adding Insecure: 1 to your Info file (or passing insecure=1 as linuxrc parameter) — but after pressing “Yes” produced yet again Nil (still no call to /sbin/multipath).

After about three hours of fiddling with the original DUD (sadly the UCS blades are painfully slow to reboot — takes them about six minutes each), I decided to repack the Driver Update Disk. The Update Media HOWTO explains the structure/layout of the DUD pretty well, but fails to mention what kind of image it actually is or how to create it. Luckily there’s Google and the Internets.

The guys over at OPS East Blog, posted something that helped me create the DUD.

Basically, create /tmp/update-media and copy/move the linux folder into this folder.

After this, we create a Driver Update Disk configration.

Now, we create the DUD package.

This produces a CramFS image named /tmp/driverupdate (which you can view using mount -o loop). After moving this image to my install location and keeping the filename driverupdate, /sbin/multipath is actually being called as you can see below.

WDS and multi-architecture boot images

Well, I recently stumbled upon another cute bug/feature with Windows Deployment Services. When you already have 32bit boot images (as we do) and then add an 64bit boot image (which we needed, since the drivers for UCS firmware v2.0 only support Windows Server 2008 R2) you still only see the 32bit images.

Why ? Because apparently the client (in my case a UCS blade) isn’t reporting it’s architecture correctly in the PXE phase. Microsoft actually has a KB article for this. You only need to enable architecture discovery.

That’s it. Once you boot the next client via PXE, you’ll see the 64bit boot image.

Convert a bunch of PDF documents to JPEG

Well, I found a bunch of PDF documents on my disk today, which I wanted converted to JPEG. Now, Debian replaced ImageMagick in the past for GraphicsMagick, which is supposedly a bit faster and leaner than ImageMagick. So first you need to install graphicsmagick — or rewrite the script to use /usr/bin/convert instead.

The script basically takes every .PDF you have in your current working directory, creates a sub-directory, and then extracts each page of the PDF into a single JPEG image in that subdirectory.

What I had to google for was basically on how to actually pad the output number. According to the man-page of gm, you just put %02d (or %03d, depending on how much pages your PDFs have at the max) in the   desired output file name.

Microsoft Cluster on VMware and Devices

Well, once again the Microsoft Cluster on VMware bit my ass … As you might know, MSCS on VMware is a particular kind of pain, with each upgrade you end up with the same problem over and over again (SCSI reservations on the RDM-LUNs being one, and the passive node not booting being the other).

So I opened up another support case with VMware, and the responded like this:

Please see this kb entry: http://kb.vmware.com/kb/1016106

This doesn’t completely fit my case, but since the only active cluster-node failed yesterday evening (it’s only our internal file-share server, thus no worries), I thought I’d try to set the options.

And guess what ? My damn cluster works again 🙂

Reconfiguring NTP settings vCenter-wide

I recently started reinstalling all my ESX hosts, so I wrote up a short script that is reconfiguring all hosts and sets the NTP configuration according to my wish:

As you can see, the script takes the vCenter hostname and two NTP servers and basically applies it to each host in your vCenter environment.

Rename a Standard Port Group on all hosts in a cluster

Well, I recently decided to rename a bunch of my Standard Port Groups, since they did no longer reflect the network they were providing. Since I’m a lazy bastard (well lazy as in click lazy), I wrote this little PowerCLI script:

This script basically takes a vCenter instance and a single cluster, then creates a new Port Group on each host, after which it reconfigures all VMs possessing a virtual NIC with that Port Group and then deletes the old Port Group.

VMware Auto Deploy already registered / RuleEngine

I had this weird plugin error the other day which bothered me on Friday. I decided to go fixing it. So after poking around in the vCenter installed software list. I couldn’t find the Auto Deploy in the list, so I figured due to my recent vCenter reinstallation while keeping the database, I forgot to reinstall Auto Deploy.

I went ahead and started the Auto Deploy setup from the DVD again, until I received this weird looking error. Apparently the setup thought (and decided correctly) that Auto Deploy was already installed in my vCenter.

So after a bit of googling, I found this nice explanation on how to manually deregister Auto Deploy from my vCenter. So here are steps retyped:

  1. Run the setup an hold at the window where you’re informed that Auto Deploy is already installed. Copy the MSI package from %TEMP%{RANDOM-GUID} to C:TEMP
  2. Unpack the setup files from the msi
  3. Manually deregister Auto Deploy using autodeploy-register
  4. Run the Auto Deploy setup again

2. Unpack the setup files:

Open a command prompt and extract the msi using msiexec

3. Switch to C:TEMPautodeployProgram FilesVMwareVMware vSphere Auto Deploy and run autodeploy-register.exe against your vCenter installation

4. After that command completes, you simply can run the setup from the DVD again. Afterwards the RuleEngine errors were gone (simply because Auto Deploy is installed again) and Auto Deploy is working again.

Using HPs vibdeposit with VMware Update Manager

As we’re finally at the point, where I only need to bother with HP hardware (which in itself is troublesome enough), I wanted to use HPs vibdeposit with our Update Manager. The whole purpose of the repository is the integration of HPs custom vibs (download able on each hardware under VMware ESXi 5.0) into the VMware Update Manager. That makes it easy to integrate, say the nmi-sourcing driver, into the VMware built ESXi images.

So basically what you do is, add the VIB repository to your vCenter Update Manager download list, and then create a dynamic baseline for everything “Hewlett-Packard” and attach that to the desired level of your environment (I did it at the root level, as I only have Hewlett-Packard). But I’ll show you.

First, visit your Update Manager (you’ll find it under Solutions > Update Manager). We need to update the Configuration of Update Manager in two places. First under “Configuration“, the second is under “Baseline and Groups“. But lets start with “Configuration“, since you can’t add something to a baseline that isn’t there.

Now, you want to add a new Update source:

The URL for that repository is http://vibsdepot.hp.com/index.xml. After that is done, you can click on “Apply” and “Download Now” to add the packages to your local software repository. After this, the VIB’s from HP just need to be applied to a set of hosts.

Now, we’re going to “Baseline and groups“.

As I mentioned before, we need to create the baseline, otherwise you can’t apply the VIBs to your hosts. So we create a new Baseline named “HP Update Bundles” only containing updates/patches labeled “Host Patch”.

Next we want to select the baseline type. Based on your requirements you may either select Fixed or Dynamic. Since I don’t want to update the baseline each time HP releases a new VIB, I chose “Dynamic”. Keep in mind if you select Fixed, you need to select the VIB’s in the dialog window.

But since I selected Dynamic, I just need to apply a filter criteria in this next dialog, telling the baseline to select only VIB’s originating from the vendor “Hewlett-Packard Company”.

You may also exclude specific patches from this baseline using this following dialog, which I decided not to do. Next we need to switch to a set of hosts (for me, it is the root level of the vCenter as I only operate HP hosts). So navigate to the desired folder, cluster, host and select the “Update Manager” tab on the upper right.

Simply click on “Attach” and a new dialog opens from which you can select the newly created Baseline.

After this the baseline is attached to the selected folder and when you Scan/Update your hosts, this baseline is being pulled in also and applied.