[Qemu-devel] Development ideas

[Scott Conrad VanderWoude]

        Qemu is great: Before taking classes in a networking-focused college
curriculum, I learned quite a bit about networking using just one
dedicated server by having it run multiple Qemu instances communicate
with each other.  I haven't joined the Qemu development team with a bunch
of volunteer labor since the project I'm involved with to freely help
others is a different one, but please know the development efforts have
tremendously helped and been appreciated.  Thank you kindly.

        I've probably been using Qemu for a few years now, and have noticed new
versions can be few and far between: It is now over a year since 0.91's
release.  Therefore, I've decided to at least introduce some ideas I've
had since waiting until another version looks like it might take... a
while.

        For the -redir option, it would be very nice if, like the -monitor
(telnet) option, one can specify what address to listen to.  For
instance, with the montior, I find it nice to be able to listen only on
127.0.0.1 and have qemu monitor support easily available but only from
the local machine.  Similarly, I'd like to be able to have a virtual
machine running a service (such as remote access) without sharing that
service to every other machine capable of communicating to every NIC on
the machine hosting the Qemu session.  Blocking traffic from the
external NIC may be possible, but since different operating systems may
come bundled with different firewall software, employing that route is
far less convenient than if Qemu supported -redir like it supports
-monitor.

        Can we have qemu run a script for each interface that it takes down, 
just
like it runs a command for each interface that it brings up?  This way,
if the qemu-ifup script does something like creating a tun0 network
interface on the host (using the /dev/tun* or /dev/tap* files), the
qemu-ifdown could trigger a script that could be configured to taking
down that tun interface., if desired, so the /dev/tun* (which is usually
limited in number) could be recycled.  As it stands now, the choices are
to either leave the tun interface up (possibly leading to wasted
resources), or try to notice when Qemu quits (perhaps by modifying the
PID file).

        Instead of only supporting a DHCP server, can we have Qemu running an
internal DHCP Relay?  (The point of this is so special DHCP options can
be provided and configured from the same DHCP server that is used to
provide details for the real, physical machines on the network.)

        Gravis Ultrasound support: Will it simply be new to version 0.92, or is
this purposefully being kept out of mainstream Qemu for some reason (like
Intellectual Property concerns)?  Adding a new sound card may take more
effort than the previously-mentioned tweaks, but I had seen it at Mac's
GIT repository
http://repo.or.cz/w/qemu/malc.git?a=commit;h=052aedb6c704c4f4b9d6875db35d8e1eeaffeade
and now at
http://svn.savannah.gnu.org/viewvc/trunk/hw/?root=qemu
and some versions of Qemu documentation on the web seem to refer to it. 
However, I haven't been seeing it included in the pre-compiled Qemu
packages bundled with the operating systems I've been using, and so
haven't experienced it yet.

        Is there any sort of public timetable to estimate when a new version is
going to be released (like two days or two years from now)?  I don't mean
to be a whiny user, but if there is such information published and I just
don't know about it, I'd like to know about it.