Cymen’s Blog

I’ve switched from a Virtual Private Server hosted at Gandi.net in France to one hosted by Prgmr.com in California. I switched because the prices increased at Gandi.net after the beta and the latency was beginning to get annoying (from Wisconsin, USA). Prgmr.com is attractive because the prices are very reasonable and the RAM allocation for the price generous. I’m paying about 1/2 – 2/3 of the Gandi price but getting twice the RAM and disk space. The one thing that Gandi did have going for it is that the bandwidth was unmetered (but capped). However, for my purposes, the Prgmr model of X GB per month is not an issue.

The setup process was quick and the VPS is performing great with my minimal usage. I’m happy with the switch and would definitely recommend considering Prgmr as a VPS provider. I have no need for a high end VPS at this time but when I do, the options at Prgmr will definitely be the the first I’ll consider.

On a final note, at first I attributed the slow console feel of the VPS at Gandi to latency but after comparing the feel between Gandi and Prgrmr and the latency figures, I’d put some of the Gandi slow down to low CPU allocation for the single slice VPS offering. I suspect Prgmr is more generous with not only the RAM but the CPU slices which is excellent for those looking for a well performing but small VPS.

I wanted to use Debian testing in a Xen DomU but after upgrading (including grub), “xm create ” no longer worked. It failed with the error:

Error: Boot loader didn't return any data!

I followed the suggestion of running “pygrub /path/to/xen/disk” but each of my DomU get a chunk of LVM disk. Within the LVM logical volume, the DomU OS partitions the disk however it wants. I need to get at one of the partitions inside the LVM from the Dom0 or Xen host OS. To do this, get kpartx and run it like so:

kpartx /dev/physical_volume_name/logical_volume_name

After running that, I found my disk partitions from the DomU logical volume at /dev/mapper/logical_volume_name1, 2, 3, etc. So I could then run:

pygrub /dev/mapper/logical_volume_name1

That error out again but it was line 68 of GrubConf.py:

def set_disk(self, val):
val = val.replace("(", "").replace(")", "")
self._disk = int(val[2:])

I added the Python lines to print out the value of val and found that it was getting set to an empty string. Then I simply mounted the now accessible root partition:

mount -t ext3 /dev/pv/lv1 /mnt/tmp

And editing the …/boot/grub/menu.lst revealed the debian upgraded and spewed some cruft into the file. Cleaning that up resulted in a working DomU. The upgrade probably mentioned this but I glazed over it. I suspect I’m not the only one so it’s worth a check.

Finding kpartx made it worthwhile…

This is a work in progress and I’m still testing some things but here are a few ideas:

1. Use the GPL Paravirtualization drivers
2. Disable the login screen saver

This basic approach works:

1. Power down target system.
2. Create another logical volume the same size as the target system.
3. dd if=/dev/$PV/$TARGET of=/dev/$PV/$CLONE bs=1M
4. Copy Xen config and modify with clone details
5. Power up clone, change hostname and any other relevant details
6. Power up target

For a 32 GB LV, dd took just over 11 minutes to dump the data from the target volume to the clone volume on my hardware. This was for a Windows Server 2003 clone using DHCP so the only thing I changed was the host name (so far).

I’d think the LVM snapshot method might be able to do this more intelligently but I couldn’t quite grok it right away and this method worked.

I got a Windows Server 2003 Xen DomU up and running within a couple hours. The configuration was fairly simple but the issue I ran into with Debian Lenny was that that Xen defaults to xenbr0 as the network bridge interface while eth0 is the correct one to to use. After modifying /etc/xen/xend-config.sxp (actually, I first stated the bridge explicitly in my DomU configuration), networking worked and the VM fired up with the regular install screens. The integration with VNC works very well.

The next step after all the OS updates was to install the Windows paravirtual drivers. I used gplpv_fre_wnet_x86_0.10.0.69.msi and the VM rebooted after install without issue except for the IntelIde drivers/service failing to load (guessing it just needs to be disabled — not critical as far as I can tell).

So far, with my DomU installs, I’ve been doing it the hard way by which I mean I’ve been reinstalling from scratch with each new DomU. Next on the list is to clone a VM using LVM snapshots which should be much easier (and reduce all that update downloading and configuration).

Update: Indeed, the IntelIde startup error is apparently fixed (hidden properly) in Xen 3.4!

I’m using a Debian 5 (Lenny) host with Xen 3.2 from packages with software RAID and LVM. At the moment, all of my guests (DomU) are also Debian 5. To resize a guest filesystem, in Dom0 resize the logical volume:

lvextend -L +100G /dev/$PV/$LV

In guest (DomU), resize the partition by deleting and creating again. The trick is to make sure the first block stays. With the default steps on the Debian netboot installer with the “all in one” option, it makes these partitions:

/dev/xvda1 as / (1st primary partition)
/dev/xdva2 as extended partition
/dev/xvda5 as swap

So I unmounted the swap (swapoff /dev/xvda5), deleted all of the partitions, recreated /dev/xvda1 as the new size marked bootable leaving just enough room for the swap partition, and added the small swap partition. Then edit /etc/fstab to point to the new device (I changed swap to be on /dev/xvda2), reboot and do “resize2fs /dev/xvda1″. I tried doing this without the reboot but resize2fs didn’t want to see the new partition sizes. I used cfdisk for the partitioning so maybe it would work with fdisk or parted.

I did forget one detail — I rebooted the DomU after resizing the LVM volume in Dom0. Mentioning just in case that is required. I’ll find out next time I need to add more space to a logical volume.

Download “osol-0906-x86.iso” and mount it using loopback (mount -o loop -t iso9660 /root/osol-0906-x86.iso /tmp/MOUNT_POINT). Copy off two files required for the install. One site suggested /usr/lib/xen-solaris:

mkdir /usr/lib/xen-solaris
cp /tmp/MOUNT_POINT//mnt/tmp/platform/i86xpv/kernel/unix /usr/lib/xen-solaris/unix-0906
cp /mnt/MOUNT_POINT/boot/x86.microroot /usr/lib/xen-solaris/x86.microroot-0906


The Xen DomU configuration:

name = 'open-solaris'
memory = '512'
disk = [ 'file:/root/osol-0906-x86.iso,6:cdrom,r', 'phy:/dev/thor/open-solaris,xvda,w' ]
vif = [ '' ]

on_shutdown = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'
extra = '/platform/i86xpv/kernel/unix - nowin -B install_media=cdrom'


Then kick off the VM:

xm create -c open-solaris.cfg


Now Open Solaris should boot up. These accounts are preconfigured:
Username: jack
Password: jack
Root password: opensolaris

The installer is GUI-only. The installer appears to kick off a vnc instance (or Xen does, haven’t looked into who/what/where but xenstore has the VNC password but the guest has the vnc process?). To get the VNC password:

xenstore-ls|grep password


To get the IP of Open Solaris:

ifconfig -a


Now you can VNC to the IP address, use the VNC password and kick off the install.

Sites referenced:

http://www.tardis.ed.ac.uk/index.php/OpenSolaris_Xen_domU
http://blogs.sun.com/levon/entry/opensolaris_2008_11_as_a
http://blogs.sun.com/levon/entry/opensolaris_2008_11_guest_domain