|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: Machine-readable or parseable qemu output |
Date: | Thu, 15 Jan 2009 14:28:56 -0600 |
User-agent: | Thunderbird 2.0.0.19 (X11/20090105) |
Avi Kivity wrote:
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? - 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");qemu chrdev ("tcp:host:port", etc)
Yes. The QEMU chrdev code can be reused too.
- The strings in qemu monitor can change but the libqemumonitor has to change accordingly as well to keep the API consistent.No, they can't. The monitor client and qemu will be upgraded independently.
+1
- The API could be something like: - execute_qemu_command(qemu_instance, command, args...);It'd much prefer qemu_hotplug_nic(...); qemu_migrate(..., callback);
I concur.
- 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.No, the command handler should parse the output expected from executing the command. If the command is asynchronous, the command handler should provide a callback.
Agreed. Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |