Interacting with the virtual machine's output/display

Overview of situation/resolution

Interacting with the virtual machine may seem very simple if the virtual machine is a visible window: in many cases it may be as simple as clicking on the window to make it active. However, there may be some complications:

  • When the virtual machine software is run, the visual display of the virtual machine will be implemented by the virtual machine software. However, this visual display might not, at least initially, simply be shown in a graphical window on the video output of the computer running the virtual machine software.

    For example, with the Qemu software, the display being used for output can be set to a VNC server rather than displaying on the X window session. Using an alternate display like this may provide an easy way to work with the machine remotely, and also may help work around problems with displaying to a local graphical screen (such as if the virtual machine is run from a text mode environment, possibly on a system which isn't even running any sort of graphical user interface). (That may be more likely when the software is running from a remote command prompt shell.)

  • The virtual machine software may start out by having the emulation frozen.

    For first time users, it may be nice to make the emulator's display visible first. This way the entire experience can be seen. (Experienced users, who are familiar with what that looks like, may want to unpause the emulation first, so that a system boot can complete while action is taken to ensure the system is visible. For users who would like to see the whole process from the beginning, the recommended course of action is to first work on being able to see the system's output.)

  • The software implementing the virtual machine may take control of the mouse cursor, prohibiting the mouse cursor from exiting the window of the virtual machine. Other keystroke combinations, such as task swapping with Alt-Tab, may be sent to the virtual machine instead of the host environment. As a generalization, keystrokes are more likely to be sent to the remote system (instead of being processed locally) if the system is being viewed full screen, rather than in an unmaximized window. As generalizations, pressing the right Alt key, or holding Control/Ctrl and Alt, may help input be recognized by the host machine's interface. Numeric function keys, such as F11 (full screen toggle, a key also used by web browsers) or F8 (used by at least some VNC software), may also help.

The first task covered here will be to start seeing the visual output of the virtual machine software. Note that this visual output may simply be a blank screen until the emulation is later unpaused, which will be the next issue to be covered.

[#seevmdsp]: Accessing the local display(s) of virtual machine(s)

Note that some implementations of virtual machines may not bother to show any real display until after the emulation has started. Therefore, make sure that the emulation is started and not paused emulation before spending a lot of time troubleshooting while the visual display might not be working.

Locally seeing the virtual machine

This may not seem hard: once the virtual machine software is running, it may be visible on the screen. Or, it might not be.

For rodent fans...

Note that if (now) and/or when (later) Qemu is shown in an X window, Qemu may “grab” control of the mouse cursor. That sounds great when the desire is to click on something showing in the Qemu window, but it is also nice to know how to make the program “ungrab” the mouse cursor so that the mouse may be used to again interact with the host environment (short of needing to shut down the virtual machine and hope that the software ends up ungrabbing the mouse then).

If QEmu has control of the mouse cursor, check the title bar of the application (if this is rendered in the GUI), as it may show what keystroke combination to use to regain control of the mouse. Otherwise, simply try ones that are likely to work: the default is to hold both Ctrl and Alt simultaneously. Qemu documentation: section titled “Invocation” may alter what needs to be pressed by using some parameters (“ -alt-grab” causing Ctrl-Alt-Shift to be used, and “ -ctrl-grab” to cause the right Ctrl key to be used for this purpose). Whatever the sequence is, if the Qemu program is active, pressing that sequence when Qemu does not have the mouse might cause Qemu to grab the mouse.

If the screen is not seen...

If X Windows is running but the Qemu window is not visible, a very possible reason is that Qemu is not sending output to the window.

Perhaps the first thing to check, as this can be easily checked from any command prompt, is to see if the command line included a reference to any of the display options.

[#seevmcmd]: Seeing what command line options created a virtual machine
To see what the command line options were, either check what is running (which is the generally preferred method, although it may take a bit longer for a first-timer to do), or view the command line history (if the virtual machine was directly run from the command line), or view the script file (if the virtual machine was run from a script file, and if that script file wasn't modified after the virtual machine had started to run).

One example would be if a reference to VNC is made. If so (even if the command line says “-vnc none), then the system can (now, or soon) be accessed (even from the local machine) by using that remote access protocol. In that case, on the plus side, once the visual screen is seen locally, getting this to also work remotely will likely be a relatively simple matter. See Remotely Accessing the local display(s) of virtual machine(s).

(At the time of this writing, Qemu may not support video accelleration. Qemu may be even less likely to be positively affected by video accelleration if output is going over a remote video output display. However, that won't really be mattering much if this computer is just being used as a network server. If VNC was specified, try out using VNC locally, as described in the section about Remotely Accessing the local display(s) of virtual machine(s) and/or VNC and Qemu, and see if the results fit the needs suitably.)

Otherwise (in the case that Qemu's command line doesn't reference VNC), check if any of the other display options were specified on the command line. (See Qemu's Documentation: Invocation section (online, or by reviewing a local qemu-doc.html which might be in a location like /usr/local/share/doc/qemu/) and check out the “Display options” section. See if any of those are being used.

Otherwise, try going to the terminal that ran the Qemu software, and running:


If that is unset, then that is probably a good indicator of why the visual output is not being shown in X. If that is set, it may be worthwhile to see if another X program can be started from that command prompt, and if that program is visible. If such a program is not visible, then a simple troubleshooting hint is that the problem probably isn't specific to the virtual machine software.

Seeing a Qemu window without VNC
This text should be merged with the previous section, as it may be redundant/repetitive/identical/etc.

If one is NOT using the command line option “ -vnc ”, then the above VNC option is not available (even if trying to use “change vnc” in the Qemu monitor). However, other options may be available.

[#qmlclgui]: Seeing Qemu using a standard graphical user interface

The Qemu documentation (section on “Invocation”) explains under the -nographic option, “Normally, QEMU uses SDL to display the VGA output.” (This is not a recommendation to use the -nographic option, but the documentation on that option was relevant to using this approach to outputing the display.)

Simply running Qemu without an option related to the display may cause Qemu to simply show up as an application using an “X Window” display. This will often be the simplest thing for people who:

  • are running Qemu from a graphical environment;
  • and expect that the virtual machine will or may show graphics;
  • and either:
    • do not want to try to currently access the virtual machine from a remote computer,
    • or who have some alternate remote-access method already implemented.

For many people, those descriptions may be accurate, and so this may be the easiest method.

One main thing to check on is to make sure there are no alternate command line options: there should be no reference to -display or one of the older variations, such as -vnc or -curses. (References to -vga, or -std-vga for older versions of Qemu, are fine.)

For Unix-based systems, one may choose to use the X Window System. To do this, first make sure that an X Window System environment is actively running. Set the $DISPLAY variable from the command prompt which will start running Qemu. (The command prompt that runs Qemu does not have to be a command prompt that was created on the X Window session.) To see the current value of the variable (which may appear blank), run:


In most simple cases, which do not involve X forwarding, the desired value will be “:0.0”.

For example, users of the Bourne shell (sh) and largely-compatible shells (e.g. ksh and bash, but not csh) may want to run the following command:

export DISPLAY=:0.0

(Naturally, after setting the variable it may make sense to run the “ echo $DISPLAY ” command again to verify that the variable was successfully set. (This sort of habit might catch typos, and potentially unexpected issues such as when an environment changes due to something like some usage of the sudo command.)

(The export command may not work with some alternate shells. Users of other shells may want to check out the details on handling operating system environment variables.)

There are other methods of remotely accessing the visual display of a program.

[#qemoutxt]: Output directly to text mode

If the virtual machine is going to be sending output as text mode, then Qemu can simply display that output as a text application. This is done using compatibility with a computer programming code library that is called “curses”, or one of the subsequent and largely inter-compatible variations such as “ncurses”.

Preparing the host environment

First, some discussions on the host environment will be appropriate. Qemu will tend to support the video standards (e.g. the VGA standard) of a common resolution such as 80 columns by 25 rows. The terminal needs to support this.

If using PuTTY

If Qemu is going to be run from a prompt that was created with SSH, and if the SSH client is a copy of PuTTY on Microsoft Windows, then note that PuTTY may default to 24 lines. This option simply needs to be changed. With an existing session, choose the program's System menu (by pressing Alt-Space if that is enabled under Window\Behavior, or by using a rodent and clicking on the upper-left corner) and choose “Change Settings...” On PuTTY's “PuTTY Configuration” screen (for a still unconnected PuTTY) or PuTTY's “PuTTY Reconfiguration” screen (if PuTTY is connected), select the word “Window”. (The word “Window” is not just a group, but it is an actual configuration screen.) If the entire remote system's screen is going to be devoted/reserved for use by Qemu, then choose 25 rows. If there is going to be a row taken up by a status bar for a screen multiplexer (such as tmux or the program called “screen”), set the number of rows to 26 (so the status bar uses one row, and there are 25 rows left for Qemu).

Using tmux

If using tmux, the terminal multiplexer (which is bundled with modern versions of OpenBSD), there is a “size” for each tmux “session”. (This is different than any settings related to the size of a window pane.) To have a nice experience with curses, if the operating system is going to be displaying 80x25, then the actual terminal also needs to be at least 25 lines. (This has been experienced and documented using OpenBSD's installer, which seems to support a properly implemented 25-row terminal. Other terminal heights might be far more unpleasant to try to use.)

At the time of this writing, the author of this text has not yet found/confirmed a way to convert an existing tmux session to a new/different height. However, here are some instructions for creating a new tmux session which is a suitable height.

If using a 26-row display with tmux

The following is assuming a Bourne-compatible shell. Otherwise, the export line may need to be altered. (See handling environment variables for variations used by other shells.)

stty -e | head -1
stty rows 26
export ROWS=26
tmux new-session -d -s virtmach -y 26

(Then, see the remaining instructions after this section about what to do if using a 25-row display.)

If using a 25-row display with tmux

The following is assuming a Bourne-compatible shell. Otherwise, the export line may need to be altered. (See handling environment variables for variations used by other shells.)

stty -e | head -1
stty rows 25
export ROWS=25
tmux new-session -d -s virtmach -y 25

Then, verify the (probably still insufficient) results with the following command:

tmux list-sessions

The output of that last command may have a format that is something like this:

virtmach: 1 windows (created DOW MON DD HH:MM:SS YYYY) [80x24]

Now, the resolution that is being reported in this example might really be quite unacceptable for trying to run Qemu. That resolution shown between the square brackets needs to be at least 25 rows tall, not 24 like what is shown in the previous example. So, to fix that, first run:

tmux attach -t virtmach

(The parameter after the -t is the session name, which was identified after the -s parameter when the session was made.)

Now, from within the session, press the tmux “prefix key”, which by default is ^B (meaning Ctrl-B, as described by control sequences).

Then, after pressing that prefix key, type the following line of text.

:set status off

To (hopefully) be clear, after pressing ^B (Ctrl-B), press a colon, type three words, and then do press the Enter key.

Then, to check things out, detach the tmux session by pressing the prefix key (^B) and then the lowercase letter d.

At this point (regardless of whether the directions for a 26-row display or the directions for a 25-row display), go ahead and run this:

tmux list-sessions

The output of that last command may have a format that is something like this:

virtmach: 1 windows (created DOW MON DD HH:MM:SS YYYY) [80x25]

If the second number in the square brackets (the number showing after the x) is 25 (or, perhaps, at least 25?), then the tmux session may be suitable for running Qemu from.

Go ahead and attach the tmux session by running:

tmux attach -t virtmach
Perform a check on the display preparation

At this point, running:

stty -e | head -1

should say (amongst other details) “ 25 rows;

That number needs to be 25 (or perhaps at least 25) for at least some environments (including OpenBSD's installer).

Adjusting the command line
Having the right command line options
Enabling curses

To enable the output to the curses library (which results in output as a text application), make sure the command line includes a reference to -curses.

This might be old info: perhaps using -display curses is preferred with newer versions? However, older versions may have simply used -curses? (Older versions might have not supported this at all.)

To have a clear, simple configuration of a single-display virtual machine, make sure that there are no -display command lines, or similar commands related to providing contrary details about exactly how the Qemu program should proceed to output the video data to the end user (such as -vnc). Command line options related to the specifying the emulated video hardware, such as -vga (or -std-vga for older versions of Qemu), are fine. Just do not have conflicting options about how the emulated video should actually be displayed to the end user.

Enabling the Qemu monitor from another window

The emulated machine might not support pressing Ctrl-Alt-2 to change the “virtual console”/“Virtual console” to the monitor, as the documentation seems to indicate. So, make sure there is another method of accessing the monitor. This can be done by including a -monitor command.

The Qemu User Documentation (available on the system by running man qemu) has little to say about the -monitor command, except that it uses the “same devices as the serial port”. For more details about the -monitor command, check out the documentation related to -serial. For example, new enough versions of Qemu support using the following:

-monitor telnet:,server,nowait
Leave Qemu in the foreground

(This section may be fairly specific to Unix-ish platforms; it might not apply at all to Microsoft Windows.)

Some sample command line scripts may demonstrate how to have Qemu run in the background. That makes a lot of sense if the plan is to interact with Qemu via VNC. However, that might not make nearly as much sense when the plan is to interact with Qemu by using the local system.

Make sure to not be backgrounding the program, if that is not desired. So, if the last character on the command line is an ampersand, remove that ampersand. (This probably needs to be done if the ampersand is the last character on the command line, or if the ampersand comes just after a semi-colon or a right-parenthesis.)

For example: the documentation on making a Qemu virtual machine configuration may show a command line that starts with a left parenthsis (the “(” character) and then contains an embedded “command line” that says qemu, and then that embedded command line ends with a semi-colon (;), and then there may be another embedded command line that outputs the results, and that embedded command line may end with another semi-colon (;), and then there may be a right parenthesis (the “)” character). That complicated command line, which is defined by parenthesis (and includes both of the embedded “command lines”), may be backgrounded with an ampersand after the parenthesis.

Note that backgrounding Qemu might not be as good of an idea as it seems. A preliminary attempt to do so seemed to indicate that backgrounding Qemu might screw up timing: booting was instant, and Qemu seemed to output a lowercase letter a senselessly.) So, beware of these sorts of potential problems if wanting to try to background Qemu by using an ampersand. (A safer way to effectively background Qemu while using -curses may be to run Qemu from within a terminal multiplexer, such as tmux or screen.

Misc notes

(An update shows the moment of ncurses support for Qemu being added.)

Qemu documentation: section called “Invocation” has information on “Display options” such as “ -curses” which might be useful. (Perhaps it might have unexpected results if other display options are always used?)

Other displays

The number of displays supported by Qemu has increased over time. At one point, an internal VNC server has been added. At another point, curses started to be supported. With this track record, it would not be terribly surprising if Qemu may someday support additional options.

Qemu documentation: section called “Invocation” has information on “Display options” such as “ -curses” which might be useful.


Run the Hyper-V manager.

This software may show that the virtual machines are running. Select one of the virtual machines. When a virtual machine is selected/highlighted, the bottom of the manager may show a tiny preview window. That might be enough to see some basic information, like if a screensaver is running or, if not, whether there is a giant error message box in the center of the screen. A full-sized window may be visible by double-clicking (... on the preview window? Or on the highlighted name of the machine?).

[#vmdsprac]: Remotely Accessing the local display(s) of virtual machine(s): (overview)

note: This hyperlink anchor may pre-date #seevmdsp, and it may be that some hyperlinks should go to seevmdsp instead of vmdsprac.

If the software can be viewed on a local display, and if networking is already set up, then there generally should not be any problems with using remote access to allow that screen to be controlled remotely. Alternatively, if the virtual machine software's output is being funneled through a remote access protocol, then the software may not be visible locally but will be able to be viewed using “remote access” software. (The remote access software client can, naturally, be run on a remote computer. It can also be run on the local computer.)

Security issues (often unknown/overlooked)

However, if using a remote access method to see the display, make sure to review the security considerations of the remote access software, such as unencrypted passwords and/or unencrypted session traffic. At least some remote access protocols have information about security considerations in the remote access section. This information, about the security considerations, may be near (but not in) a section that describes various software programs that provide support for using the protocol. For example, the VNC protocol security considerations section has information that should be reviewed before implementing a solution that uses the VNC protocol.

Actually, that section about security considerations for VNC may be worthwhile reading for users of other protocols as well, to see an example of what considerations there are with at least one mainstream protocol. Those considerations may be things to specifically check for when using any other remote access protocol.

The reason for the extra emphasis, to take time to check out the security considerations to become familiar with them, is because because all-too-often some of these security considerations are not known by many people who deploy their implementations of a specific remote method (and possibly subsequent implementations as well). Some of the fault for that may be some non-standard behaviors being misleading (such as VNC servers allowing a user to specify a longer password, and then only checking part of the information entered).

After becoming familiar with those considerations, address them. For example, especially with VNC (since VNC solutions may commonly (and needlessly) use multiple ports), be sure to check which TCP ports are actually being used before feeling like completed success has been achieved. (Note: listening to extra TCP ports, particularly if bound only to loopback addresses, isn't necessarily a bad thing. There may be positive reasons for that to occur, and this may be fully okay if such potential communications are being effectively controlled. The goal here isn't to fully stamp out listening on anything beyond just one TCP port. The goal, however, is to be fully knowledgable about what TCP ports are being listened to, including knowing which network addresses those TCP addresses are being listened on, so that appropriate measures like firewalling can fully control what ports are being used.)

Often tunneling network traffic ends up being worth reading.

Following are some more specific details that may help (in some cases) to make remote access work for the virtual machine softare.

[#qemunvnc]: Seeing Qemu with VNC

Qemu has an internal VNC server. It is generally suitable for use, although certainly another option (which was usable even with older versions of Qemu, before Qemu started having an internal VNC server) is to use other remote access software (such as other VNC software).

[#qemvncsv]: Using a VNC server to show Qemu's display

This is part of the equation. (Also see the section about setting up a VNC client.) Choose an option, possibly using some details in this section. (Also, make sure to review the earlier, more generalized information about remotely access virtual machine's local displays, since at least some of the security considerations mentioned in that section will apply to VNC connections.)

[#qemvncin]: Using Qemu's internal VNC server
[#qemvncli]: Setting Qemu's VNC command line option(s)

The first thing to verify is that the command line parameters have Qemu using its internal VNC server as the method of displaying video output. This is taken care of if the VNC server was activated with command line parameters such as “ -vnc none -usbdevice tablet ”.

(The word “ none” simply means some values are not pre-set, but the fact that -vnc is being specified will cause Qemu to run in a way so that a VNC server can later be specified, even though the word “ none” is used. That is recommended so the actual VNC connection will not be creatable until it is manually enabled (which can be delayed until the VNC session is nearly ready to actually be created).

[#qemenvnc]: Enabling Qemu's VNC server

This is actually a multi-step process, and so there is a separate section documenting the process of Enabling Qemu's VNC server.

Using Xvnc and/or a different VNC server

The page on Remote Access methods (section on “Remote framebuffer” and VNC programs) provides information about options. Note that despite its name, Xvnc does not require a separate implementation of the X Window System. (Rather, it is a simplistic implementation of a working X Window System.) Therefore, if one is wanting to avoid setting up a standard full/complex X Window environment just for VNC capabilities, Xvnc may be an excellent choice. (Xvnc was proven to be a working method historically, before using newer versions of Qemu that had an internal VNC server.)

If using a program that uses the X Window System, before running the program, make sure that the X Window System is running and that the $DISPLAY variable has been set.

Using a VNC client

Make sure that routing traffic from the remote access client to the remote access server will work. Specifically, this may involve reading a bit of the details on the guide about creating a port forwarding rule with SSH to create an SSH tunnel. That information may be used to forward a TCP port above number 5900 on the system with the VNC server to a TCP port above number 5900 on the system with the VNC client. (That approach is likely to work well, although in case other options are sought, there might be other solutions involving routing traffic from the remote access server to the remote access client. Reviewing that section is recommended if needed to get a working setup.)

The page on Remote Access methods (section on “Remote framebuffer” and VNC programs) provides some software. For information on installing the software, see the section about software installation.

If a connection, such as an SSH tunnel, does not seem to be working, make sure that the intended TCP ports are being used. Attempting to use the standard IPv4 notation may end up actually specifying a VNC desktop number, instead of a TCP port number, when using software that uses the standard notation for software that uses the VNC protocol.

Note that some of VNC-based remote access software may wish to work with a VNC desktop number: At least with IPv4, these VNC desktop numbers may be specified using the syntax of an IPv4 followed by a colon followed by a VNC desktop number. Despite looking identical to a standard notation of an IPv4 followed by a colon followed by a TCP port number, the VNC desktop number and the TCP port number typically are not identical, and are offset by 5900.

Other virtualization software
[#pausedvm]: Resuming a paused session (and pausing a session)

This may be done with the Qemu monitor. First are some details about how to use the monitor, in general, and then come the details that are specifically about unpausing the virtual machine.

[#useqmumn]: How to use the “Qemu monitor”
Using the standard (interactive) Qemu Monitor
Seeing the Qemu monitor

There are various methods of being able to access the Qemu monitor.

Accessing the monitor from a network connection is an effective way which allows the monitor to be easily remotely accessed. (That method will be covered more extensively in the upcoming section about command line parameters related to the “ -monitor ” command line parameter.)

Locally using the Qemu monitor

Another ways to access the Qemu monitor may involve pressing one of the key sequences to switch to the monitor, although those key sequences may not always work. (At least with older versions of Qemu, in at least some environments (perhaps being used in an old version of Xvnc running under an old version of OpenBSD), perhaps when certain command line options are or aren't used, certain key sequences may not work.) However, if the keyboard keys (see Qemu documentation: section 3.4: Keyboard keys with special meanings for Qemu) are providing access to the monitor, a method may be to press Ctrl-a and then to press c. Alternatively, holding Ctrl and Alt and pressing 2 may work. Naturally, if using an environment where Ctrl-A is trapped (such as if using the software called “screen”), escaping the keyboard input may be necessary. (In the program called “screen”, pressing Ctrl-A followed by the letter “a” will send the desired Ctrl-A to the program that is running within “screen”, since that is how the screen program operates.)

The method of entering the monitor may vary based on the command line parameters. Check the command line for a -monitor option. A nice option is to use “ -monitor telnet”.

(The “ -monitor tcp” is an older option that pre-dates “ -monitor telnet”, although “ -monitor tcp” may work well initially with a telnet client. However, with at least some versions of Qemu, the “ -monitor tcp” may not work as smoothly in some scenarios, such as when a connected telnet client stops and then a new connection is created.)

An example command line for qemu uses “-monitor telnet:,server,nowait”. Since the monitor is a telnet server listening to IPv4 address and TCP port 7211, run the following command (from a command line):

telnet 7211

Several notes about that command line (some, or even all, of which might not be relevant):

  • The TCP port number specified is customizable. To determine the actual TCP port number to use, be sure to check the command line that was used to create the virtual machine. The brief paragraph about seeing what command line options created a virtual machine covers options to see the command line that was run.
  • Unlike the syntax specified to Qemu, the telnet command likely does not require a colon attaching the IPv4 address with the TCP port number. In fact, telnet is likely to not work with that colon. Qemu, however, does require the colon.
  • Because is on a loopback interface, the command will need to be run on the machine that Qemu is running on.
  • Nicely, that example telnet command provided should work with both Unix and Windows.
  • More details about using programs that use the Telnet protocol may be covered in the section about section about (the remote access protocol) Telnet. As a quick example, for people who are doing this on a system that is running Qemu under Microsoft Windows: if PuTTY (Microsoft Windows version) has been placed in the path or if it is in the current directory, Windows users may prefer to use the command line “ PuTTY -telnet -P 7211 ”.

This should show a banner (e.g. “QEMU version-number monitor - type 'help' for more information”) on one line, followed by a Qemu monitor prompt. The Qemu monitor prompt has the word qemu surrounded by parathesis, followed by a space (so it looks like this: “(qemu) ”).

Using the visible “Qemu monitor”

help” shows some commands and “info” shows others, although together these help screens are still incomplete. The monitor section of qemu-doc provides even more details.

Interactions via Telnet

If the monitor is being run off of a Telnet server (because of command line parameters that say “ -monitor telnet,” then the monitor doesn't (or at least shouldn't) quit the connection (unless the virtual machine software is quitting). The telnet client will need to break the connection.

To quit the monitor when using a telnet session, simply end the telnet session. The exact method to do that may vary based on which remote access telnet client is being used. If using the default telnet program bundled with many operating systems, be careful to make sure that the “quit” is only typed at the “telnet> ” prompt. Specifically, make sure not to accidentally type “quit” and press enter if the “(qemu) ” prompt is the most recent prompt provided to the user, for doing this will cause the virtual machine software to quit, stopping the guest virtual machine when doing so.)

Automating this a bit more

Although this might be possible using some sort of automation involving a telnet program of some sort, there is an effort to create a rather automatable solution using the QEMU Monitor Protocol (“QMP”). The web page shows an example of using this by using a “ -qmp” command line parameter. Essentially the commands look like they have some similarities to the standard interactive monitor, but the input and output are in a different format. Qemu's page on the Google Summer of Code 2010 project to improve QMP has some other info related to QMP.

However, note that it may not be worthwhile spending quite a bit of effort/time trying to heavily automate enabling VNC to be able to view the virtual machine software running on the host machine. Instead, the eventual plan for many virtual machines may be to enable remote access to the virtual machine. Once that is set up, there may be little need to interact with an interactive interface provided by the virtual machine software.

Continuing and pausing with the monitor

To continue a “stopped”(/paused/frozen) emulation session, enter the c command into the “Qemu monitor”. Changing some of the options related to the visible display may also be something that the “Qemu monitor” can affect, although command line options may also be impactful.

info to pause/stop/hold the machine to be added. The c command is an abbreviation for the cont command which is an abbeviation for the word continue (although the full word continue is not a valid command).

The command line option “ -S ” may be used to start the emulator in a stopped state. One way to not need to specify to continue each time may be to just make sure that the command line doesn't include a “ -S ” to stop the emulator.