wiki:Testing

Testing LinuxPMI under QEMU

Setup

kernel

You need to download and build a kernel to test first. See the GitLinuxPMI-HOWTO for directions on how to accomplish this.

initrd

To test LinuxPMI, it is recommended that You build an initrd image containing 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=ttyS0" \
-net nic,model=e1000,macaddr=52:54:00:12:34:57 \
-net socket,mcast=230.0.0.1:1234 \
-serial pty

This will start the kernel/VM with a single serial port, connected to kgdb.

At the QEMU command console, you can type 'info chardev' to find out what pts is connected to that serial port.

Important Note: Be sure to change the macaddr argument to be different for each machine that is invoked, otherwise 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=ttyS0" \
-net nic,model=e1000,macaddr=52:54:00:12:34:57 \
-net socket,mcast=230.0.0.1:1234 \
-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

Using the pty retrieved from the qemu command prompt, you can then connect GDB to the running kernel:

gdb) target remote /dev/pts/11

You should now be connected.

gdb) continue

This will start the kernel, and get it past the point at which the kernel pauses automatically. if you don't 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
Last modified 9 years ago Last modified on Oct 21, 2012, 10:04:42 AM