Christian's blog
The usual IT babble
AutoYAST and custom swap partitioning
Jun 3rd
Well, we’ve been discussing our swap partitioning the last few days at work, and I finally got around to implementing it. Again, it proved to be kinda hard, basically because AutoYAST decides to do things differently. More >
SLES10 not installing boot loader in MBR
Jun 3rd
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:
<bootloader> <device_map config:type="list"> <device_map_entry> <firmware>hd0</firmware> <linux>/dev/cciss/c0d0</linux> </device_map_entry> </device_map> </bootloader>
distributions.barfoo.org going away
Jun 3rd
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)
Jun 3rd
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:
dd if=/dev/zero of=/dev/hda bs=512 count=1
That actually does the trick. The loader as well as the partition table are gone after wards!
VMware Consolidated Backup and TRANSPORT_MODE=”hotadd”
Mar 18th
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.
- VMware Data Recovery
- VMware Consolidated Backup
- 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%\VMware\VMware 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.