phaqphaq

This week I started on evaluating an iSCSI storage system which should get connected to a Xen-enabled host. An article covering this particular topic is in preparation.

Since the iSCSI device offered management capabilities over serial console I though to attach it to COM1 (/dev/ttyS0) of my host system.
This is well the point when I noticed that Xen had already grabbed /dev/ttyS0. Since my host system offered only one serial port and I didn’t have a spare serial server at hands I needed to change this behaviour to get it working.

By means of ‘dmesg’ it can be easily verified if Xen grabbed the serial port:

# dmesg|grep ttyS0
Xen virtual console successfully installed as ttyS0

Then make sure you know which kernel version you’re running:

# uname -r
Linux gic-ftp-lin-001.genotec.ch 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007 x86_64 x86_64 x86_64 GNU/Linux

Look for the corresponding kernel section in your grub.conf (or whatever boot loader you use).

title Red Hat Enterprise Linux Server (2.6.18-8.el5xen)
        root (hd0,0)
        kernel /boot/xen.gz-2.6.18-8.el5
        module /boot/vmlinuz-2.6.18-8.el5xen ro root=LABEL=/
        module /boot/initrd-2.6.18-8.el5xen.img

Then add the ‘xencons’ option to the module line stating the kernel arguments.

title Red Hat Enterprise Linux Server (2.6.18-8.el5xen)
        root (hd0,0)
        kernel /boot/xen.gz-2.6.18-8.el5
        module /boot/vmlinuz-2.6.18-8.el5xen ro root=LABEL=/ xencons=tty6
        module /boot/initrd-2.6.18-8.el5xen.img

In this case I added ‘xencons=tty6′ to have Xen grab /dev/tty6 for it’s console.

Other possibilities are:

After changing this line and rebooting the system I could finally connect my iSCSI’s serial terminal.

It seems impossible at first to run the NVIDIA binary driver on Linux x86_64 when Xen is enabled.

That’s because NVIDIA does not support Xen in the first place albeit there’s some demand for it for sure.

Luckily the only things to be changed are within the kernel interface contained in the driver package. There exist already a lot of patches on the net, I took mine from nvnews.

You can grab a copy of the patch from my site, too.

The following instructions are derived from my steps in getting NVIDIAS’s binary driver to work on Fedora Core 6 running Xen on the x86_64 platform (Intel Core 2 Duo 6420 CPU).
It was verified to work with driver version 1.0.9755 (march 29, 2007) and 1.0-9639 (may 29, 2007), both of which you can get from the NVidia website.

First you need to have some prerequisites installed on your system:

• toolchain (gcc, make, etc.)
• applicable kernel headers (I had kernel 2.6.20-1.2948.fc6xen on my system, so I installed kernel-xen-devel-2.6.20-1.2948.fc6 and kernel-xen-2.6.20-1.2948.fc6 packages)

Then the appropriate driver packages needs to be downloaded and extracted to a temporary directory:

mkdir /tmp/nv_xen
cd /tmp/nv_xen
wget http://us.download.nvidia.com/XFree86/Linux-x86_64/1.0-9639/NVIDIA-Linux-x86_64-1.0-9639-pkg2.run
/bin/sh NVIDIA-Linux-x86_64-1.0-9639-pkg2.run -x
Creating directory NVIDIA-Linux-x86_64-1.0-9639-pkg2
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86_64 1.0-9639.

Also get a copy of the NVidia Patch for XEN:

wget http://phaq.phunsites.net/wp-content/uploads/2007/06/nvidia_xenpatch.gz

Then change to the source directory, apply the patch and compile the driver.
The kernel source is required. If installed properly it should be located at /usr/src/kernels. If more than one exists choose the right one according to your ‘uname -r’ output.

cd NVIDIA-Linux-x86_64-1.0-9639-pkg2/usr/src/nv
zcat ../../../../nvidia_xenpatch.gz | patch -p4
[output omitted]
make SYSSRC=/usr/src/kernels/2.6.20-1.2948.fc6xen-x86_64/ module
[output omitted]
NVIDIA: left KBUILD.

If the compile run succeeds you should see the message NVIDIA: left KBUILD by the end of the output.
If anything weird happens, e.g. build process aborts, either the patch did not apply cleanly, the headers are not up to date or your sources are not configured.
In the last case a simple ‘make oldconfig’ from the kernel source directory may be enough to get it fixed.
There’s also the chance that you try this patch on a non-supported kernel source version or NVIDIA driver package which may prevent successful compilations.
Since I did not implement the patch by myself I cannot be of much help in either case.

Upon successful compilation you can install and load the driver. Verify that the driver loaded by means of ‘lsmod’.

install -D -o root -g root -m 0644 nvidia.ko /lib/modules/`uname -r`/video/nvidia.ko
depmod -a
modprobe nvidia
lsmod|grep nvidia
nvidia               7771096  22

At this point run the NVIDIA installer to get the remaining utilities.
Use the ‘no-kernel-module’ option as you installed the kernel module already.

cd ../../../
/bin/sh nvidia-installer --no-kernel-module

This is it! You are now ready to configure your X server to use the NVIDIA driver.
Stick to the docs included with the driver on how to achieve this.

This is my Xorg sample configuration with twin-view enabled accross two displays at 1280×1024 resolution.

# sample Xorg configuration file for NVIDIA graphics driver

Section "ServerLayout"
	Identifier	"Default Layout"
	Screen		0  "Screen0" 0 0
	InputDevice	"Keyboard0" "CoreKeyboard"
EndSection

Section "Module"
	Load	"dbe"
	Load	"extmod"
	Load	"record"
	Load	"xtrap"
	Load	"freetype"
	Load	"type1"
	Load	"glx"
EndSection

Section "InputDevice"
	Identifier	"Keyboard0"
	Driver		"kbd"
	Option		"XkbModel" "pc105"
	Option		"XkbLayout" "ch"
	Option		"XkbVariant" "de_nodeadkeys"
EndSection

Section "Device"
	Identifier	"Videocard0"
	Driver		"nvidia"
	Option		"TwinView" "1"
	Option		"CursorShadow" "1"
	Option		"TwinViewOrientation" "RightOf"
	Option		"MetaModes" "1280x1024,1280x1024"
EndSection

Section "Screen"
	Identifier	"Screen0"
	Device		"Videocard0"
	DefaultDepth	24
	SubSection "Display"
		Depth	24
		Modes	"1280x1024"
	EndSubSection
EndSection

Back some time I announced reviewing FreeBSD’s geom software RAID implementations.

Todays article compares geom stripe (gstripe) along with geom gvinum (gvinum) for disk striping (RAID0).

All testing was done on the same hardware as before to get results comparable to previous tests.

Benchmarks were taken using stripe sizes of 64k, 128k and 256k and measured using dd, bonnie++ and rawio as before.

As for the technology gstripe follows the same approach than gmirror which I look at previously.

# rawio benchmark results

rawio was choosen to measure I/O speed during concurrent access. rawio was set to run all tests (random read, seq read, random write, seq write) with eight processes on the /dev/stripe/* and /dev/gvinum/* devices.

Results for the single disk are provided as well to compare performance not only between the different frameworks but also against the native disk performance.

Click the images to see the actual result values and a chart.

* WPG2 Plugin Not Validated *

* WPG2 Plugin Not Validated *

# dd benchmark results

dd was choosen to measure raw block access to /dev/mirror/* and /dev/gvinum/* devices. dd was set to run sequential read and write tests using block sizes from 16k to 1024k.

Click the images to see the actual result values and a chart.

* WPG2 Plugin Not Validated *

* WPG2 Plugin Not Validated *

# bonnie++ benchmark results

finally, bonnie++ was used get pure file system performance.

Click the images to see the actual result values and a chart.

* WPG2 Plugin Not Validated *

* WPG2 Plugin Not Validated *

# conclusion

Looking at raw disk access I must conclude that none of the frameworks beats single disk performance in overall when it comes to blockwise input/output with dd.
gvinum generally performs better than gstripe except when using 256k stripe sizes.

Now since ‘dd’ is very synthetic by it’s nature, rawio is much better to see how the devices would perform under a more “real-life” situation.
Although rawio benchmark results may look low, these numbers where achieved by running 8 processes at once. They’ll reflect best what could be expected in a true multi-user environment with concurrent access.
As from the results there is no absolute winner, as depending on the stripe sizes either of both implementations out-performs the other.

Finally for bonnie++ we see some interesting results. Performance is almost identical for all implementations.
One notable exception was seen with gvinum (64k stripe size) which clearly outperformed its competitors..
One must keep in mind that the first six tests performed by bonnie++ (rand delete/read/create, seq delete/read/create) are limited by I/O performance of both the system bus and the device itself. The hardware I used for testing was capable of about 160 – 170 I/Os per second. I admit that results could be different if the tests are re-run on decent hardware with a higher I/O throughput. It’s possible that modern hardware reveals an I/O barrier for abstracted devices which cannot be seen from my tests.

Personally I prefer using gstripe over gvinum because of it’s more simplistic configuration approach. In terms of performance, gvinum seems to offer superiour performance when it comes to disk striping.

The next article will discuss gvinum and gstripe for RAID10.

When initiating a PPP/PPTP connection through Windows RAS you will usually end up with an altered network default route which will redirect all and every traffic through PPP/PPTP.

There are many cases however where such a behaviour is simply not desired, considering Windows RAS providing you with no way to circumvent this, you’re on your own for once more.

I wrote this script, ras_init.vbs, out of the requirement to restore my default route for normal connections and route only specific hosts and networks through PPP/PPTP.

ras_init.vbs is released under the terms of the GNU GPL, version 2. Any feedback is appreciated.

Current Relese:

ras_init-0.3.zip

Older Releases:

ras_init-0.2.zip

Change Log:

r0.3 2007/06/06

• fixed a bug with wrong RAS_Routes array enumeration
• changed script to figure out language settings on its own
• addedd support for RAS_Name, RAS_User and RAS_Pass attributes to include whitespace characters
• added support for Windows Vista (requires administrative privileges though)

r0.2 2006/06/16

• add support for interactive/non-interactive mode

r0.1 2006/06/13

• initial release
• tested on Windows 2000/XP
• searches through all interfaces and looks for the expected RAS subnet address
• removes RAS default route and replace it by your local default route
• optionally set up host/network routes for routing through RAS