Re: [Qemu-devel] Re: Re: QEMU GUI-Frontend based on Libvert API

[James Olsen]

Hello everyone,

I've actually tried to do some of these things myself a few months
back. I thought I'd have a daemon or "control" program that would
manage the QEMU instances.

A new instance would be launched by a controller app with a few of
additional parameters. One is a custom window title (I added -t
parameter support, which sets the title of the window). So if you had
two QEMU instances open, the title of one would be "ABC" and the other
would be "XYZ", or whatever you named that virtual computer in the
control app. I found that while I was testing, having more than one
QEMU window with the exact same title is less cumbersome.

Also passed at startup was a unqiue ID string generated by the
control app. It is used to identify that instance. Lastly, the control
app passes it's own process ID. The the QEMU instance contacts the
control app with it's unqiue ID, and then control app knows the
process ID of the instance. From this point on the two processes can
communicate with each other, since they know each other's process ID
and can send messages.

I then tried to modify the SDL sources and QEMU sources to support
receiving messages sent to the window, similar to how (at least
Windows) operating systems work. You can send an app's window a
"minimize", "maximize", etc., messages and the app will respond to
them. So I investigated and found that there is a range of commands
set aside specifically for applications to use (they won't collide
with system messages). So I figured I'd enumerate various QEMU
commands into that region, such as savevm, etc. I then added code to
the SDL/QEMU event loop to process those custom commands and
translate them into the traditional commands and then let the event
loop process the command as normal.

It all worked, but my C/C++ is amateur enough that despite everything
I tried my string parameters came through corrupt a good chunk of the
time. And I've tried allocating my own memory, making copies of the
parameter asap before it was deallocated by the OS, etc., but I never
did get it stabilized before I ran out of time to work on it. The
string is necessary for some commands, such as the loadvm/savevm to
specify the path/filename of the image.

With this support in QEMU, then any controlling application can easily
manage QEMU transparently.

Of course, it doesn't address wrapping controls around the QEMU window
like VMWare does, but a controlling app would only need to implement a
VNC client and map it to a window region or something to that effect,
I suppose. I don't know much about the innerworkings of VNC but it
seems plausible.

--
James
Funny quotes: "There are 10 types of people in the world. 
Those who understand binary, and those who don't." -- Unknown
"A computer once beat me at chess, but it was no match for me at
kick boxing." -- Emo Philips