Features/GuestAgent/UsefulCommands: Difference between revisions

Latest revision as of 21:29, 2 January 2013

Summary

This page tracks possible additional guest-agent commands that will make management life easier.

Owner

Name: (Up for grabs)
Email:

Detailed Summary

Additional guest agent commands may make management life easier.

Implementation

update-time

Right now, when a guest is paused or migrated to a file then loaded from that file, the guest OS has no idea that there was a big gap in the time. Depending on how long the gap was, NTP might not be able to resynchronize the guest. Adding a new guest-agent command that is called any time a guest is resumed and which tells the guest to update its own wall clock time based on the information from the host will make it easier for a guest to resynchronize without waiting for NTP. It might look something like:

{ 'command': 'guest-update-time', 'arguments' : { 'seconds': 1343862720, 'nanoseconds': '123000000' } }

to force the guest to set its time to an absolute value. If the guest is set to run at a different offset from UTC than the host, then the host will be responsible for fudging that delta factor in before handing it to the guest. Or maybe would it be better to just tell a guest to advance its clock by a delta, where the delta corresponds to how long the guest was paused (but then qemu would have to let management know when the guest was paused in order for the management app to compute the proper offline duration).

See this libvirt post that first suggested the idea.

guest-info enhancement

Right now, management apps can determine which commands a guest supports via guest-info, but cannot tell which of those commands are expected to return a value on success (vs. success only being observable via side effects, such as guest-shutdown). It would be nice to expose the success-response member of each command in qga/qapi-schema.json either into the existing GuestAgentInfo type, or else via a new guest command for querying more details about a given command.

@@ Line 23: / Line 23: @@
 See this [https://www.redhat.com/archives/libvirt-users/2012-July/msg00141.html libvirt post] that first suggested the idea.
-* guest-commands
+* guest-info enhancement
-Right now, there is no way to know which command a guest supports, short of trying a command and detecting failure when it is unsupported.  This is made worse by the fact that some commands in the same version of guest-agent are conditional (for example, commands that are available only on Windows or only on Linux guests, even if the guest-agent code comes from the same qemu version) and that some commands are expected to have no return value on success (where trying a command and getting no error could mean the command succeeded, but could also mean the agent died before returning an error that the command is unknown).  Contrast this with QMP query-commands, which makes it possible to learn all supported commands.  Adding support for:
+Right now, management apps can determine which commands a guest supports via guest-info, but cannot tell which of those commands are expected to return a value on success (vs. success only being observable via side effects, such as guest-shutdown). It would be nice to expose the success-response member of each command in qga/qapi-schema.json either into the existing GuestAgentInfo type, or else via a new guest command for querying more details about a given command.
-{ 'command': 'guest-commands', 'returns' : [ 'GuestCommandInfo' ] }
-along with enough useful information about each command (such as whether a response is expected on success) will make it easier to write management code that can adapt to what the agent actually supports.