The above post has some interesting discussion of maintaining screen output, I’ve got one solution and the comments suggest a better option.

Jason White wrote the following in a comment on my maintaining-screen-output post, unfortunately WordPress doesn’t let me move a comment to a different post so I’ll just paste it in:

My earlier attempt to post failed (probably my fault), and I have further
comments to add anyway.

1. http://womble.decadent.org.uk/blog/kvm-reliability

2. Be sure to use the Virtio drivers for the network and block devices:
http://www.linux-kvm.org/page/Virtio

3. Kernel Shared Memory (KSM) may be useful if you plan to run multiple KVM
guests.

Ben Hutchings has announced that Xen kernel images are now being prepared for Squeeze.

Ben points out that the problem with recent kernels crashing under KVM on AMD is due to a regression in a security fix and should be fixed soon.

These are just settings which work well for me. I don’t claim they are optimal and I didn’t run benchmarks. But perhaps there is some useful option you missed.

For starting kvm in background I use the following options:

kvm -vnc none -monitor unix:/home/jan/VM/vm1/monitor,server,nowait -daemonize

With -vnc none, an internal vnc server is started, but not connected to any port. As I usually don’t access the console, this is fine. If I need console access for some reason, I can connect to kvm using something like ‘nc -U ~/VM/vm1/monitor’ and enter ‘change vnc 127.0.0.1:x’ to bind the vnc server to port x.

To shutdown the vm I can use
echo “system_powerdown” | nc -q 30 -U /home/jan/VM/vm1/monitor

For networking, I prefer a tap device. This seems to be the most flexible option, as I can add it to a software bridge, use routing,
firewalling etc. just like on a physical interface. As I don’t want to run kvm with root privileges, I add a tap interface
in /etc/network/interfaces:

iface tap_jan0 inet manual
tunctl_user jan
up ifconfig $IFACE up
up ip route add 192.168.1.2/32 dev $IFACE

tunctl_user makes this device accessible by an unpriviliged user, so kvm can be run as a normal user. I use the following options:

-net nic,model=virtio,macaddr=02:00:00:00:10:02 -net tap,ifname=tap_jan0,script=no

model=virtio should be faster than the default and is fine when running a moderately recent linux as client OS.

The same is probably true for disk devices, but I didn’t try that, yet:
Instead of using -hda, one can use -drive file=…,index=0,media=disk,if=virtio

The only stability problem I had with this system (host cpu: AMD Athlon(tm) 64 X2 5600+) was that kvm didn’t like frequency scaling on
the host, which I disabled with
devices/system/cpu/cpu0/cpufreq/scaling_governor = performance
in /etc/sysfs.conf.
I should probably find out if this problem is solved by now to gain the power saving advantages of frequency scaling, as I installed the system more than a year ago and didn’t touch these settings since then.

I hope some of these settings are useful to you.