Features/GuestAgent/UsefulCommands: Difference between revisions
(new page) |
(→Implementation: modify command list RFE, based on what I learned today about guest-info) |
||
| (One intermediate revision by the same user not shown) | |||
| 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-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. | |||
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.