/dev/zero

Having hosed a Gentoo guest on a VMware ESXi host by filling the partition (which VMware really doesn’t like) then attempting to fix it by mounting the partition in anther guest and fsck’ing it first, I got the error message “the parent virtual disk has been modified since the child was created” when I tried to boot the original Gentoo guest.
Googling pointed me to a nice post at Recovering VMware snapshot after parent changed.
Step two lists the following caveat:

“Look at the size of the snapshot virtual hard disk. If it is more than 2GB and you’re running a 32-bit OS, or it is more than the amount of memory that you have available, the following method will probably not work. You’re welcome to try though.”

I found this wasn’t an issue as it appears (at least as of ESXi 4.x) VMware has separated the vmdk “header” and “data”, putting the “header” in the “hostname.vmdk” file and the actual data in “hostname-flat.vmdk”. The original vmdk is now only a couple of hundred bytes and easily edited in vi. Grabbing the CID from the Gentoo.vmdk and modifying parentCID in Gentoo000001.vmdk had me back up and running (at least to the point that I could now boot the Gentoo guest, using an Ubuntu ISO so I could access the file system and clean it up. I moved /home to a new partition, fixing the space issue).
Next time, I’ll just be smart and build all systems with LVM, then I can just add more physical extents when I need more space.

Running Dog Leaugue has a good write up on how to install VMWare ESXi on a thumb drive.
With this I was able to get it up and running on a Dell PowerEdge 850 that would NOT install ESXi from a CD (couldn’t find a storage device to install to).

I finally got a CentOS 5 domU running under Debian.
The xen-tools xen-create-image method didn’t work. I managed to find an appropriate build script for centos5, but it was pretty badly out of date, trying to install RPM versions that don’t exist on the mirror servers any more. Trying to bring it back up to date would have been a PITA. It has the RPM versions hard-coded in the script.
However the instructions at http://wiki.kartbuilding.net/index.php/Create_Centos5_DomU_on_Debian_Etch_Dom0 worked a treat.
After following those steps, I converted it from a file-based image, to an LVM, with the following steps:
Manually create logical volumes for the filesystem and swap. I use 40G filesystem LVs and 128M swaps.

# mkdir /mnt/loop
# mkdir /mnt/cenots
# mount /home/andrew/centos.5-0.img /mnt/loop -o loop
# mount /dev/mapper/ember-centos5–disk /mnt/centos
# cd /mnt/loop
# cp -Rp bin boot dev etc home lib media mnt opt root sbin selinux srv sys tmp usr var ../centos
# cd
# umount /mnt/loop
# umount /mnt/centos

Then edit /etc/xen/domains/centos.cfg and change the following lines:

kernel = “/boot/vmlinuz-2.6.18-4-xen-686″
ramdisk = “/boot/initrd.img-2.6.18-4-xen-686″
vif = ['bridge=xenbr0']
disk = ['file:/xens/name_of_new_server_to_be/centos.5-0.img,sda1,w','file:/xens/name_of_new_server_to_be/centos.swap,sda2,w']

To:

kernel = ‘/boot/vmlinuz-2.6.18-6-xen-686′
ramdisk = “/boot/initrd.img-2.6.18-6-xen-686″
vif = [ 'ip=192.168.1.13' ]
disk = [ 'phy:ember/centos5-disk,sda1,w', 'phy:ember/centos5-swap,sda2,w' ]

Then “xm create centos”. Boom! Centos 5, running as a domU on a Debian Etch dom0, from a logical volume.
And I still have the original centos5 image file for creating fresh domUs.

Aught to be a good title for a book on Xen, no?

Anyway, while discussing Xen with the COO (and it just occurred to me, really this project should be the CTO’s, not the COOs… odd how the COO does all this stuff…) he came to the conclusion that, like openVZ and Virtuozzo, Xen guest systems shared the kernel with the Host. That didn’t sound right to me, but I couldn’t disprove it with my Xen server, where every DomU had an empty /boot.

So I updated the kernel in Dom0, but didn’t reboot. I now have a newer kernel installed than the one it’s currently running.
I then tweaked the /etc/xen-tools/xen-tools.conf and built a new DomU, to use the new kernel. Everything went without a hitch. I now have a Dom0 running 2.6.18-4-xen-686, with a domU running 2.6.18-6-xen-686. So it would seem that while they all “share” a kernel in the sense that they share a single install on the hard drive (all pulling from the dom0 /boot directory), they aren’t sharing a single instance of the kernel in memory.

I then tried to get a working CentOS 5 domU running, but ran into some snags. That will be another post.

So far this week I’ve:
Finally gotten a working Xen system that will boot a Debian guest.
Successfully installed ispCP on the Debian guest.
Built another Debian guest to be an OpenVPN server.
Successfully built an OpenVPN server and got two clients to connect from outside the network, through the DSL modem/router.
Correctly configured the VPN server to give the client access to the full network via IP masquerading (next trick: get the network to simply route the packets instead of having to use masq).
Got ddclient working on the VPN server to keep dyndns updated so I don’t have to hard code an IP address in my VPN clients and check various server log files to see if it changed.
Fixed ddclient, when it failed to update dyndns with new IP address after my DSL provider mysteriously issued a new one, not 3 hours after setting up ddclient in the first place.

I can now log into my ispcp box from my desk at work, as though it was on the same network. I can now proceed with trying to get Mailman to play nice with ispCP when it’s slow at work.

I get productive when I ignore my games.

While installing Ubuntu Server 8.04 beta on an HP DL-320, I discovered I had some trouble getting HP’s “Proliant value added software” (hpasm) package installed. This package contains their system health check and control software which, among other things, switches the fans from “full-time full speed” (which is quite noisy) to temperature controlled speed (eg: normal (read: quiet) fan speed when system temp is normal).
The problem with installing and runnning this software stems from the fact that Ubuntu, for some reason, links /bin/sh to dash instead of bash. Dash is another bourne shell clone, but doesn’t understand Bash (bourne-again shell) specific syntax.
Re-linking /bin/sh to bash instead of dash solved the problem and the server is now humming (quietly) along.