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
* - Tong - mlist4suntong@yahoo.com [20070901 15:55]:
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. :-)
Hey, I wrote the stuff for http://grml.org/qemu/ ;)
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.
Just press ctrl-alt-2 *inside* running qemu and use 'info kqemu' then. What does it return?
- 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.
Sorry, I've never used a qcow overlay image on my own. Maybe someone else on this list has experience in using it and can write some words about it?
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
[...]
Excellent idea, thanks - will be implemented soon, you can track it via http://bts.grml.org/grml/issue275
regards, -mika-
Teilnehmer (2)
-
- Tong - -
Michael Prokop