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

[Daniel P. Berrange]

On Wed, Jan 14, 2009 at 04:40:05PM +0530, Amit Shah wrote:
> 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?

I'd like to add one more requirement

 - Works with existing QEMU monitor for releases >= 0.8.0

This is because libvirt currently supports all QEMU >= 0.8.0, so if
we're to be able to make use of this library we can't restrict it
to just new releases. If it can't then we have to keep our existing 
monitor interaction impl around and thus adding a 2nd impl using
this library wouldn't be much of a benefit. 

> - 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");

Also need ability to attach to a TTY, and/or a pre-opened file
descriptor.

> - 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);

I think it'd be better to return all relevant data in the API used
to invoke the command, rather than just restricting to a int return
code. Having to run a separate API here means we have to have the extra
complexity internally to keep the last command string in a thread-local
data storage. 

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

Agreed - having a 2nd monitor console for emitting async events is much
simpler way to go.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|