[Top][All Lists]

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

Re: stdio vs mon:stdio

From: Pascal
Subject: Re: stdio vs mon:stdio
Date: Wed, 1 Apr 2020 09:29:57 +0200

hi Peter,

thank you for these explanations which answer perfectly to my need (which is only occasional).

regards, lacsaP.

Le mar. 31 mars 2020 à 17:22, Peter Maydell <address@hidden> a écrit :
On Tue, 31 Mar 2020 at 15:45, Pascal <address@hidden> wrote:
> my goal is to be able to easily pass commands to qemu from my terminal without the risk of terminating/killing qemu with an unfortunate Ctrl-C and also to be able to push groups of commands there via a script .

If you want to be able to script sending commands to
the QEMU monitor I think you'll find that's most easily
done by sending the monitor output somewhere else
(eg to a TCP socket), so it's not tangled up with
the guest terminal output. You can do that with
something like:
  -chardev socket,id=monitor,host=,port=4444,server,nowait,telnet \
  -mon chardev=monitor,mode=readline

which will make QEMU open a listening socket on port 4444.
You can then 'telnet localhost 4444' to connect to it.
For scripting I like 'expect'; here's an example expect
script which will connect to a running QEMU with a monitor
on port 4444, tell it to 'continue' (in this case I'd
started QEMU with '-S' to make it not boot the guest until
told to continue), wait briefly, do a 'savevm' and then
shut down QEMU:

#!/usr/bin/expect -f

set timeout -1
spawn telnet localhost 4444
expect "(qemu)"
send "c\r"
sleep 0.2
send "savevm foo\r"
expect "(qemu)"
send "quit\r"
expect eof

There's no problem with having multiple monitor connections,
so you can use those options together with '-serial mon:stdio'
which gives you both the telnet 4444 connection for the
scripting, plus the usual 'C-a c' to get at a second monitor
prompt for whatever manual stuff you want to do (and
avoids having 'C-c' kill QEMU).

PS: scripting via what we call the "human monitor protocol"
is fine for small stuff, but if you plan to do more heavyweight
remote control of QEMU you probably want to investigate the
"QEMU Machine Protocol (QMP)", which is a JSON-based protocol.
You get basically the same functionality but in a more easily
machine-parsed format, and we give API stability guarantees
for QMP which we don't give for HMP.

-- PMM

reply via email to

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