Features/GuestAgent/UsefulCommands: Difference between revisions
(new page) |
(→Implementation: suggest guest-commands) |
||
| Line 17: | Line 17: | ||
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: | 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': 'update-time', 'arguments' : { 'seconds': 1343862720, 'nanoseconds': '123000000' } } | { '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). | 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 [https://www.redhat.com/archives/libvirt-users/2012-July/msg00141.html libvirt post] that first suggested the idea. | See this [https://www.redhat.com/archives/libvirt-users/2012-July/msg00141.html libvirt post] that first suggested the idea. | ||
* guest-commands | |||
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: | |||
{ '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. | |||
Revision as of 04:36, 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-commands
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:
{ '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.