Re: [Qemu-devel] QEMU feature idea: simple macros/scripting

["John R. Hogerhuis" <jhoger@pobox.com>]

On Fri, 2004-10-01 at 02:54, Johannes Schindelin wrote:

> > 5) In the guest only; such utilities exist for Windows and probably some
> > other OSes.
> >
> > Not sure what the pros/cons are exactly. (5) can be ruled out since you
> > wouldn't be able to script at the QEMU level (saving/loading system
> > state images and such [...])
> 
> Well, not exactly true. You can run a job which looks on the second hard
> drive (if that exists) for a script, and then savevm. When you now run
> qemu loadvm'ing that state, you supply a second hard drive image et voila!
> 

Actually in that direction, it strikes me that the guest is the most
efficient and accurate place to record events, if at all possible, since
then, say instead of recording a mouse position and a button click, the
recorder instead saves the window id of the button and the message that
goes to it. And it would be more likely to work properly even if a
window shows up in a different place on a given run than the other
possible solutions.

In that case it would make sense to design a formal communication
channel between QEMU and a player/recorder piece running in the guest,
so that QEMU could send/receive portions of the script that must run in
the guest and get notified at transition points (including exceptional
occurences) so QEMU could execute portions of the script only it can
(like savevm).

VmWare has "Vmware Tools" which run in the guest, which adds remote
control of the graphics driver among other things. From what Lionel
said, it sounds like there is something that is part of the WINE project
which could be utilized here, and it could be made part of a package for
QEMU analogous to VmWare Tools.


-- John.