Testing LinuxPMI under QEMU

Setup

kernel

You need to build a kernel to test with. LinuxPMIKernelBuilding?

initrd

First you'll need to build an initrd. This initrd image must contain the migtorture suite.

Download busybox 1.15.2 from  http://busybox.net/downloads/busybox-1.15.2.tar.bz2 and extract it into 2.6/tools/initrd_builder/

As root, or using sudo, run mkinitrd.sh in the same directory. The script does the following;

  • Make an image
  • Formats the image ext2
  • Loopback mounts the image
  • Builds busybox using the included config and installs it to the initrd
  • Builds the migtorture suite
  • Copies a few libraries
  • Compresses the initrd

Node

./mkinitrd.sh

This will build an initrd that will start up, bring up eth0, and attempt to get an address using dhcp.

Server

./mkinitrd.sh server

This will build an initrd that will start up, bring up eth0, assign eth0 the address 192.168.168.12 (The default address that migtorture will attempt to migrate to), and start a small dhcp server that will assign addresses in the same subnet.

kgdb/qemu

to run these tests, QEMU and GDB need to be installed on your local machine.

Running LinuxPMI under Qemu

Invoke qemu with at least these options: 

qemu -kernel bzImage \
-initrd initrd.gz \
-append "ramdisk_size=34000 root=/dev/ram0 rw kgdbwait kgdboc=ttyS1" \
-net nic,model=e1000,macaddr=52:54:00:12:34:57 \
-net socket,mcast=230.0.0.1:1234 \
-serial stdio \
-serial pty

You'll get something like this: 

char device redirected to /dev/pts/11

Important Note: Be sure to change the macaddr argument to be different for each machine that is invoked, else things will break.

Optionally you can add a few more useful arguments. 

qemu -kernel bzImage \
-initrd initrd.gz \
-append "ramdisk_size=34000 root=/dev/ram0 rw kgdbwait kgdboc=ttyS1" \
-net nic,model=e1000,macaddr=52:54:00:12:34:57 \
-net socket,mcast=230.0.0.1:1234 \
-serial stdio \
-serial pty \
-vnc :0

Attaching GDB

Run gdb on the host system. needs to be invoked with vmlinux as the argument otherwise you wont have debugging symbols. 

gdb /path/to/vmlinux

connect to kgdb 

gdb) target remote /dev/pts/11

You should now be connected. 

gdb) continue

This will start the kernel, if you dont want to do this, remove the kgdbwait from the append argument to qemu.

When stuff breaks

gdb) bt

Will display the backtrace

KVM

kvm will work just as well as qemu, the only difference being you use the kvm-qemu binary instead of the qemu binary.

migtorture

migtorture is fairly straight forward to use, assuming you are using the server and node initrds to automatically setup networking, you login as root with no password into a node image and run it. 

migtorture

It will then start a series of tests designed to break things, either in a minor way such as a process dying, or very major such as a kernel panic.

For kernel panics or stack dumps, refer to the kgdb section above on how to obtain a backtrace.

New testing tools

spook has began writing some new testing tools.

Currently;

  • Harness starts
  • It forks, and exec()s forker
  • forker SIGUSR1s the parent harness
  • harness SIGUSR1s the child forker
  • forker forks
  • local forkers signal each other
  • harness checks its own /proc/$pid for /pms/where and terminates if it doesn't find it, signalling the forkers so they self-terminate.

Planned;

  • harness migrates a forker
  • pipe/signal between local harness and remote forker
  • pipe/signal between remote forker and local forker
  • harness migrates local forker
  • pipe/signal between harness and a remote forker
  • pipe/signal between the remote forkers
  • harness migrates a remote forker home
  • pipe/signal between local harness and remote forker
  • pipe/signal between remote forker and local forker
  • harness migrates the remote forker home
  • pipe/signal between harness and a forker
  • pipe/signal between the local forkers