[libvirt] [PATCH 0/5] support guest agent general command
Hi, All. I rewrote the patches as Eric suggested. virsh # help qemu-agent-command NAME qemu-agent-command - Qemu Guest Agent Command SYNOPSIS qemu-agent-command <domain> [--timeout <number>] {[--cmd] <string>}... DESCRIPTION Qemu Guest Agent Command OPTIONS [--domain] <string> domain name, id or uuid --timeout <number> timeout [--cmd] <string> command virsh # qemu-agent-command RHEL58_64 '{"execute":"guest-info"}' {"return":{"version":"1.1.50","supported_commands":[{"enabled":true,"name":"guest-network-get-interfaces"},{"enabled":true,"name":"guest-suspend-hybrid"},{"enabled":true,"name":"guest-suspend-ram"},{"enabled":true,"name":"guest-suspend-disk"},{"enabled":true,"name":"guest-fsfreeze-thaw"},{"enabled":true,"name":"guest-fsfreeze-freeze"},{"enabled":true,"name":"guest-fsfreeze-status"},{"enabled":true,"name":"guest-file-flush"},{"enabled":true,"name":"guest-file-seek"},{"enabled":true,"name":"guest-file-write"},{"enabled":true,"name":"guest-file-read"},{"enabled":true,"name":"guest-file-close"},{"enabled":true,"name":"guest-file-open"},{"enabled":true,"name":"guest-shutdown"},{"enabled":true,"name":"guest-info"},{"enabled":true,"name":"guest-ping"},{"enabled":true,"name":"guest-sync"},{"enabled":true,"name":"guest-sync-delimited"}]}} virsh # qemu-agent-command RHEL58_64 '{"execute":"guest-sync", "arguments":{"id":123}}' {"return":123}
[adding qemu-devel, for a qemu-ga question] On 08/07/2012 06:04 PM, MATSUDA, Daiki wrote:
Hi, All.
I rewrote the patches as Eric suggested.
virsh # help qemu-agent-command NAME qemu-agent-command - Qemu Guest Agent Command
SYNOPSIS qemu-agent-command <domain> [--timeout <number>] {[--cmd] <string>}...
virsh # qemu-agent-command RHEL58_64 '{"execute":"guest-info"}' {"return":{"version":"1.1.50","supported_commands":[{"enabled":true,"name":"guest-network-get-interfaces"},{"enabled":true,"name":"guest-suspend-hybrid"},...
Question to the qemu folks - can we enhance 'guest-info' to tell us commands required to give output on success, vs. commands that are expected to never answer (except on possible error), so that libvirt can then make smarter decisions about whether to wait for a response for an arbitrary guest agent command? That is, I would love for the 'success-response' field of the qapi-schema-guest.json file to be exposed to libvirt, as it would greatly help in implementing Daiki's patchset for calling an arbitrary command and knowing whether to block on expecting a response rather than forcing the user to know which magic --timeout values to use. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 08.08.2012 16:36, Eric Blake wrote:
[adding qemu-devel, for a qemu-ga question]
On 08/07/2012 06:04 PM, MATSUDA, Daiki wrote:
Hi, All.
I rewrote the patches as Eric suggested.
virsh # help qemu-agent-command NAME qemu-agent-command - Qemu Guest Agent Command
SYNOPSIS qemu-agent-command <domain> [--timeout <number>] {[--cmd] <string>}...
virsh # qemu-agent-command RHEL58_64 '{"execute":"guest-info"}' {"return":{"version":"1.1.50","supported_commands":[{"enabled":true,"name":"guest-network-get-interfaces"},{"enabled":true,"name":"guest-suspend-hybrid"},...
Question to the qemu folks - can we enhance 'guest-info' to tell us commands required to give output on success, vs. commands that are expected to never answer (except on possible error), so that libvirt can then make smarter decisions about whether to wait for a response for an arbitrary guest agent command? That is, I would love for the 'success-response' field of the qapi-schema-guest.json file to be exposed to libvirt, as it would greatly help in implementing Daiki's patchset for calling an arbitrary command and knowing whether to block on expecting a response rather than forcing the user to know which magic --timeout values to use.
Even if I'd gladly eliminate this --timeout I am not so sure we can do that. Even if qemu-ga will report which commands does reply on success. I guess this is the image you had in mind: 1) user issues command X 2) libvirt asks qemu-ga if X returns an success reply 3a) if it does, wait for it 3b) if it doesn't just write command into agent's socket. Asynchronously. 4) return from API Well, current version of qemu-ga doesn't report this kind of info yet (patch against qemu-ga has been submitted). So in step #3 we can't decide whether to go with A or B path. And we can't wait for monitor event like we do now for those commands not replying on success - this command needs to be as general as possible. On the other hand, what would happen if step #2 fails, so we go with 3B then? For instance, if issued command was fsfreeze-freeze, which we've written asynchronously, users can issue fsfreeze-status to query for status. Have I got it right? Michal
On 08/21/2012 09:26 AM, Michal Privoznik wrote:
Question to the qemu folks - can we enhance 'guest-info' to tell us commands required to give output on success, vs. commands that are expected to never answer (except on possible error), so that libvirt can then make smarter decisions about whether to wait for a response for an arbitrary guest agent command?
Even if I'd gladly eliminate this --timeout I am not so sure we can do that. Even if qemu-ga will report which commands does reply on success. I guess this is the image you had in mind: 1) user issues command X 2) libvirt asks qemu-ga if X returns an success reply
2b - if no answer to guest-info in a reasonable timeout, assume guest agent is not running, and return from API immediately
3a) if it does, wait for it
although a timeout is still useful here, since the guest agent can go away at any time.
3b) if it doesn't just write command into agent's socket. Asynchronously. 4) return from API
Well, current version of qemu-ga doesn't report this kind of info yet (patch against qemu-ga has been submitted). So in step #3 we can't decide whether to go with A or B path. And we can't wait for monitor event like we do now for those commands not replying on success - this command needs to be as general as possible.
Perhaps we can be sticklers, and refuse to run arbitrary qemu-ga commands against a guest agent that doesn't report enough information. After all, the libvirt addition of 'virsh qemu-guest-agent-command' is intended as a debugging aid and future development testbed, rather than a supported libvirt interface, and when you are debugging, it is okay to require the latest and greatest.
On the other hand, what would happen if step #2 fails, so we go with 3B then? For instance, if issued command was fsfreeze-freeze, which we've written asynchronously, users can issue fsfreeze-status to query for status.
Have I got it right?
Yes - if the user is going to issue arbitrary guest agent commands, and we know the command won't reply on success, we should still wait a reasonable amount of time for an error, but we should also return control to the caller to allow them to detect the command's success via other means such as an event occurring. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Eric Blake -
MATSUDA, Daiki -
Michal Privoznik