Hi,
I was on and off with QEMU in the past because it was slow. I knew there is a kernel accelerated QEMU but never made the attempt to try it, because I was stopped by the idea that I should compile/deal with the kernel modules.
I never blame others for my own fault, but this time, mika, I think you are to blame for this. I mean, I didn't know that the accelerated QEMU works out of box in grml ever since grml v0.5 (http://www.grml.org/qemu/) -- you should be blamed for the fact that I don't know it. You made things so easy for us but never let us know. :-)
Now I will give QEMU a serious try. mika, I think your wiki can use some more explanation on the following 2 points.
- "To see if kqemu is enabled and working correctly, use the QEMU monitor command" -- please elaborate more about it, because 'info kqemu' didn't give me the desired info. Moreover, it'd be better to clearly tell uses in wiki how to do it.
- I learned that "To run the emulated system, a good idea is to use overlay images. This way you can create hard disk image once and tell Qemu to store changes in external file. You get rid of all the instability, because it is so easy to revert to previous system state." (http://manual.sidux.com/en/hd-install-opts-en.htm#qemu)
could you write something about this overlay image practice as well in your wiki please? That'll sure benefit grml users.
Furthermore, in order to make it easier for grml users, I think it is better to start kqemu the standard way, not the hacking way. Please twist the following file and release it in the future of grml:
/etc/init.d/kqemu
#!/bin/sh case "$1" in start) echo "Starting kqemu: " /sbin/modprobe kqemu major=0 # load the kernel module mknod /dev/kqemu c 250 0 # create the device chmod 666 /dev/kqemu /dev/net/tun # adjust permissions ;; stop) echo "Stopping kqemu: " /sbin/rmmod kqemu ;; restart) /sbin/modprobe kqemu major=0 ;; *) ;; esac
thanks