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

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

[John R. Hogerhuis]

I have a suggestion for a feature for QEMU:

Macros/Scripting. For the most part, on my machines Windows is a very
manual labor intensive peripheral. I haven't moved to an open source
accounting package yet, so I use Quickbooks. I use it to keep track of
invoices and consulting hours. But every time I print an invoice between
evolution and the virtual machine, copy name/address information between
the two systems and print an invoice to file, ftp that file back over to
Linux, convert it to pdf, and mail to my customer.

I think if Windows under QEMU were scriptable, that I could take several
steps out of my workflow (I imagine there are other ways I could
automate it as well).

So I think the FTP server addition for exchanging files, in concert with
some way to actually record/playback typing at the keyboard and clicking
the mouse would allow me to use Windows as a peripheral.

Similarly for Windows only hardware (no Linux driver), one could utilize
such a Mother of All Kludges.

This would also be a real boon to testers since they could easily script
out clicks and keypresses (so long as they can figure out a way to
record "evidence" of a successful test... file showing up on disk, or
maybe you allow screen captures at key points to be added to the script
and viewed by a person to determine if the test was successful).

You would probably want a way to stretch and shrink the amount of time
it takes to run different parts of the script, since just playing back
often won't work, but sometimes it does.

I don't think VmWare does anything like this, so I believe it would be
unique to QEMU.


Probably too early to add this high level feature, stability and speed
first as always, but something to cogitate on for the future.


-- John.

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

[Johannes Schindelin]

Hi,

On Thu, 30 Sep 2004, John R. Hogerhuis wrote:

> Macros/Scripting. For the most part, on my machines Windows is a very
> manual labor intensive peripheral.

I started to write a vnc frontend for QEmu. On the other end, I started to
write a scriptable vnc viewer. The use of this? Macros/Scripting for QEmu,
but also Macros/Scripting for everything which can be controlled by a
vncviewer. For now, I use an adaption of vncrec, which just records inputs
and timestamps, and play those inputs back later.

Ciao,
Dscho

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

[John R. Hogerhuis]

On Thu, 2004-09-30 at 17:19, Johannes Schindelin wrote:

> I started to write a vnc frontend for QEmu. On the other end, I started to
> write a scriptable vnc viewer. The use of this? Macros/Scripting for QEmu,
> but also Macros/Scripting for everything which can be controlled by a
> vncviewer. For now, I use an adaption of vncrec, which just records inputs
> and timestamps, and play those inputs back later.

Sounds like your solution would work for me as well. I hadn't thought of
using vnc and related tools.

I'm not sure what kind of integration makes sense, if any.

A record/playback feature could be

1) In QEMU proper wedged between the QEMU and the guest, hooked into the
data traffic
2) In a front end to QEMU which just communicates through a
to-be-implemented API; basically still #1 just architecturally different
3) In a completely separate utility that knows nothing about QEMU and
just deals with X. Such utilities exist for X
4) In a VNC viewer
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, and not all OSes necessarily have good utilities
for recording and playing back such events.

-- John.

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

[Lionel Ulmer]

On Fri, Oct 01, 2004 at 02:19:39AM +0200, Johannes Schindelin wrote:
> > Macros/Scripting. For the most part, on my machines Windows is a very
> > manual labor intensive peripheral.
> 
> I started to write a vnc frontend for QEmu. On the other end, I started to
> write a scriptable vnc viewer. The use of this? Macros/Scripting for QEmu,
> but also Macros/Scripting for everything which can be controlled by a
> vncviewer. For now, I use an adaption of vncrec, which just records inputs
> and timestamps, and play those inputs back later.

What could also be investigated is the 'regression' tool supposedly written
by CodeWeavers for Wine (I never played with it so I do not know the current
status - i.e. freely distributable or not) but it looks similar to what you
want to do: automatic button presses on dialog buttons, checking of results,
...

The problem is that I have no idea if it works at a pure 'bitmap' level or
if it needs to have knowledge of the window hierarchy and stuff like that
(i.e. hooks into Win32 or X11 via some API calls).

     Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

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

[Johannes Schindelin]

Hi,

On Thu, 30 Sep 2004, John R. Hogerhuis wrote:

> On Thu, 2004-09-30 at 17:19, Johannes Schindelin wrote:
>
> > I started to write a vnc frontend for QEmu. On the other end, I started to
> > write a scriptable vnc viewer. The use of this? Macros/Scripting for QEmu,
> > but also Macros/Scripting for everything which can be controlled by a
> > vncviewer. For now, I use an adaption of vncrec, which just records inputs
> > and timestamps, and play those inputs back later.
>
> Sounds like your solution would work for me as well. I hadn't thought of
> using vnc and related tools.
>
> I'm not sure what kind of integration makes sense, if any.
>
> A record/playback feature could be
>
> 1) In QEMU proper wedged between the QEMU and the guest, hooked into the
> data traffic

You would probably not even need that much, but just write your own
frontend (see vnc.c, or no-sdl hack for examples). Maybe a scriptable
frontend via SWIG; the main application loop would probably have to run in
an own thread.

> 2) In a front end to QEMU which just communicates through a
> to-be-implemented API; basically still #1 just architecturally different

well, actually not different, but better separated.

> 3) In a completely separate utility that knows nothing about QEMU and
> just deals with X. Such utilities exist for X

See for example xautomation: http://hoopajoo.net/projects/xautomation.html

> 4) In a VNC viewer

See my work in a few weeks/months.

> 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!

Ciao,
Dscho

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

[Johannes Schindelin]

Hi,

On Fri, 1 Oct 2004, Lionel Ulmer wrote:

> What could also be investigated is the 'regression' tool supposedly written
> by CodeWeavers for Wine (I never played with it so I do not know the current
> status - i.e. freely distributable or not) but it looks similar to what you
> want to do: automatic button presses on dialog buttons, checking of results,
> ...

I was not able to find the tool on the net, but rumours tell that it works
on the Win32 API level.

Ciao,
Dscho

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

[John R. Hogerhuis]

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.