[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Johannes Schindelin
Subject: Re: [Qemu-devel] QEMU feature idea: simple macros/scripting
Date: Fri, 1 Oct 2004 11:54:07 +0200 (CEST)


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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]