Assign hardware to DomU with PCIBack as module [Update]

If the Dom0’s kernel is built with pciback as a module (grep CONFIG_XEN_PCIDEV_BACKEND /boot/config-`uname -r`), using the kernel command-line parameter pciback.hide won’t work.

There is of course more than solution how you can assign hardware to a domU, but the probably easiest one is to to pass the hide parameter to the pciback module in /etc/modprobe.conf:

[...]
 # hide (0000:05:02.0)
 options pciback hide=(0000:05:02.0)
[...]

The xensouce mailing list even tells you how to modify your initrd preloading the pciback driver before all others

# mkinitrd -f --preload=pciback /boot/initrd-$(uname -r).img $(uname -r)

Another (maybe more elegant) solution would be assigning the pci devices in a separate init script:
http://www.bestgrid.org/index.php/Xen:_assigning_PCI_devices_to_a_domain
http://projects.arcs.org.au/trac/systems/wiki/Howto/PciBack

Update: If you want to avoid rebuilding the initial ramdisk manually every time you update your kernel, you may want to put this small script to your /etc/rc.local

/sbin/modprobe pciback
BDF=0000:05:02.0
# Unbind a PCI function from its driver as necessary
[ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
        echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
# Add a new slot to the PCI Backend's list
echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
# Now that the backend is watching for the slot, bind to it
echo -n $BDF > /sys/bus/pci/drivers/pciback/bind

With the preceding modprobe pciback the module doesn’t have to be preloaded in you initial ramdisk.

Shutting down xen domUs without saving them

Per default, CentOS 5.3 saves a domU’s state when the hypervisor is shut down. In principle this a nice behaviour: The domU will restore its state automagically when the hypervisor comes up again and just continue working. But there are some services (e.g. mldonkey) that don’t like to be restored and refuse to work (i.e. keep in a blocked state forever).

The easiest way of fixing this, is to shut down the domUs gracefully with the hypervisor. In CentOS (as in probably most other distros as well) you can change xen’s shutdown behaviour in /etc/sysconfig/xendomains

[...]
## Type: string
## Default: /var/lib/xen/save
#
# Directory to save running domains to when the system (dom0) is
# shut down. Will also be used to restore domains from if # XENDOMAINS_RESTORE
# is set (see below). Leave empty to disable domain saving on shutdown 
# (e.g. because you rather shut domains down).
# If domain saving does succeed, SHUTDOWN will not be executed.
#
#XENDOMAINS_SAVE=/var/lib/xen/save
XENDOMAINS_SAVE=
[...]

All we have to do is empty the value of the XENDOMAINS_SAVE variable, so SHUTDOWN will be executed instead.

Online resizing ext3 partitions

      16 Comments on Online resizing ext3 partitions

First, we have to delete our current partition and create a bigger one (don’t be afraid, no data will be lost):

# fdisk /dev/xvda

Type m to get a list of all commands:

Command (m for help): m
Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)

Let’s print out the partition table and look for the ext3 partition, we want to enlarge (it’s easy here, there is just one partition):

Command (m for help): p

Disk /dev/xvda: 5218 MB, 5218304000 bytes
255 heads, 63 sectors/track, 634 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1   *           1         634     5092573+  83  Linux

Now we delete the old partition (/dev/xvda1) and create a new one with the maximum available size:

Command (m for help): d
Selected partition 1

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-634, default 1): 
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-634, default 634): 
Using default value 634

Our original /dev/xvda1 had the bootable flag (see fdisk -l output), so we must add it to our new /dev/xvda1 again:

Command (m for help): a
Partition number (1-4): 1

Now let’s write our new partition table and exit fdisk:

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

After rebooting the system (!) we can online-resize the filesystem with a simple command:

# resize2fs /dev/xvda1 
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
Performing an on-line resize of /dev/xvda1 to 1522150 (4k) blocks.
The filesystem on /dev/xvda1 is now 1522150 blocks long.

Staring X applications through an ssh tunnel

If you encounter the problem of being unable to start an X application through an ssh-tunnel and run into an error message similar to

Can't open display

or

RuntimeError: could not open display

you should check

  • that you used ssh -X[...] to enable X11 forwarding when connecting to the server
  • that the xauth-package is installed correctly on your server

xauth is used to edit and display the authorization information used in connecting to an X server.

For example, after installing a minimalistic CentOS the xorg-x11-xauth package is not necessarily installed as well.

The solution is quite simple:

yum install xorg-x11-xauth

does the trick! You may have to reconnect to give xauth the opportunity to create a new authority file for you user (~/.Xauthority)

Fix for Cursor Keys in VMware server

To make the Arrow Keys (and other cursor control) work in VMware 1.0.x server:

cat >> /etc/vmware/config <<EOF
xkeymap.keycode.108 = 0x138 # Alt_R
xkeymap.keycode.106 = 0x135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0x148 # Up
xkeymap.keycode.116 = 0x150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0x152 # Insert
xkeymap.keycode.119 = 0x153 # Delete
xkeymap.keycode.110 = 0x147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0x149 # Prior
xkeymap.keycode.117 = 0x151 # Next
xkeymap.keycode.78 = 0x46 # Scroll_Lock
xkeymap.keycode.127 = 0x100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu
EOF

You can of course change vmware’s configuration per user (not globally!) by pasting the keycodes in ~/.vmware/config

Found in chrisdew’s blog

Using ssh-keygen & ssh-copy-id

      2 Comments on Using ssh-keygen & ssh-copy-id

Just because I always forget:

Step 1: Create public and private keys using ssh-keygen

[user@Host ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): 
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
0d:d2:94:07:93:a9:48:b9:33:73:fb:f1:6e:33:ce:d7 user@Host
The key's randomart image is:
+--[ RSA 2048]----+
|     .  +=       |
|    o  o+..      |
|   . o..o.       |
|    * o. o       |
|     = .S .      |
|      . .        |
|       . o   .   |
|        ..= . E  |
|         +++     |
+-----------------+

Step 2: Copy the public key to remote-host using ssh-copy-id

Now here comes the awesome part: You don’t have to scp the public key to your remote host and cat it into ~/.ssh/authorized_keys. Instead, you can use ssh-copy-id

[user@Host ~]$ ssh-copy-id -i .ssh/id_rsa.pub user@remote-host
user@remote-host's password: 
Now try logging into the machine, with "ssh 'user@remote-host'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Customizing Gnome keyboard shortcuts

      No Comments on Customizing Gnome keyboard shortcuts

It’s possible to define keyboard shortcuts for your own commands in addition to the predefined Gnome actions. Since metacity is Gnome’s default window manager, you have to edit the metacity keys in your GConf configuration system. The easiest way is doing it with the gconf-editor (although you can of course edit the xml-definition in ~/.gconf/apps/metacity/ by hand).

So open your gconf-editor and navigate to the tree ‘/apps/metacity/global_keybindings’. Assign a shortcut to one of the keys run_command_1 to run_command_12, e.g. Alt + F9.

Now you have to tell metacity, which command to run. In the corresponding key run_command_1 to run_command_12 under ‘/apps/metacity/keybinding_commands’ you specify the command that you want to attach to the shortcut.

An Example: We want to start xmms when XF86AudioPlay is pressed, so we have to alter the keys as follows

/apps/metacity/global_keybindings/run_command1  =  XF86AudioPlay
/apps/metacity/keybinding_commands/command1     =  xmms -t

Of course, this only works with the default windows manager metacity. If you use a composition-manager like Compiz or Beryl, your mileage will vary.

Continue reading