Jump to navigation Jump to search


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


  • Name: (Up for grabs)
  • Email:

Detailed Summary

Additional guest agent commands may make management life easier.


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