[Qemu-devel] Machine-readable or parseable qemu output

[Amit Shah]

Hello,

Continuing from the thread at [1], building on Daniel's suggestions, I
have jot down a few points as to how a libqemumonitor API could be
developed.

To recap, there has to be an interface to the qemu monitor in
a way that wouldn't break even if the monitor output changes. This API
will remain the same, so that consumers (libvirt, etc) can safely
integrate with the monitor.

Please see Dan's email at [1] to get the background details.

[1] http://www.mail-archive.com/address@hidden/msg14615.html

Here are some initial thoughts. Comments?

- Have a libqemumonitor.so that will abstract out output from qemu and
  provide a machine-readble output for the consumer

- Registering with a particular qemu instance:
  - qemu_instance = attach_to_qemu("/path/to/socket");

- The strings in qemu monitor can change but the libqemumonitor has to
  change accordingly as well to keep the API consistent.

- The API could be something like:
  - execute_qemu_command(qemu_instance, command, args...);

  This will then return with a value of:
  - 0: Success (no output)
  - -ve: Failure
  - +ve: Log level type from QEMU monitor output (see below)

- For qemu, a loglevel can be added so that the message output is
  disciplined (as seen in kernel printk messages):
  - term_printf(QINFO, "Beginning migration\n");
  - term_printf(QERR, "Migration failed\n");

- -ve return values can be reserved to indicate that the link with the qemu
  monitor went down or some other problem with the libqemumonitor and
  the monitor interface

- In addition to the return value seen of the loglevel type from the
  monitor, there can be additional return values that can be provided
  based on the command executed. This can be queried by:
  - get_info_on_prev_command(qemu_instance, &ret);
  - This can give command-specific return values, like success,
  invalid parameter, etc.

- The string generated by qemu monitor output should never be exposed to
  the consumer

- Some monitor commands will generate some string that might be of use
  to the consumer. Such a string will be passed to the consumer via some
  other api, like
  - get_string_from_last_command(qemu_instance, some_context);

- There might be output that's asynchronous to the command. Finding the
  correlation between the command and the output should not be the
  library's job; an async_socket can be created per qemu instance and
  the consumer can select() on this socket to poll for data. Whenever
  some information becomes available, we can push it out. If the qemu
  output would contain more information for async output, this can be
  passed on to the consumer.

Amit.