Re: [libvirt] [PATCH 0/5] support guest agent general command
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