Features/GuestAgent

From QEMU
Revision as of 01:13, 8 March 2011 by AnthonyLiguori (talk | contribs) (Created page with '== Summary == Implement support for QMP commands and events that terminate and originate respectively within the guest using an agent built as part of QEMU. == Detailed Summary…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Summary

Implement support for QMP commands and events that terminate and originate respectively within the guest using an agent built as part of QEMU.

Detailed Summary

There are two proposed ways to implement support for a guest agent today in QEMU both with advantages and trade-offs.

One approach takes QEMU completely out of the picture by exposing a guest agent over a transport (like virtio-serial) and then exposing that transport over a CharDriverState to be terminated in the management layer (ala libvirt). This model keeps complexity out of QEMU but exposes management tools directly to the guest potentially significantly increases the guest's attack surface. In addition, it makes live migration very challenging to coordinating while keeping communication transparent to the guest agent.

Another proposal terminates the guest agent directly within QEMU. This introduces considerable complexity into QEMU by creating a new RPC transport potentially increasing the guest attack surface. While it does improve support for live migration, it requires a parallel API within QMP to support management tools.

A potential middle ground is to adopt QMP as the RPC interface between the guest agent and QEMU and expose the guest commands as a QMP namespace. This eliminates the need for a parallel API, addresses live migration robustly, and by reusing the existing QMP infrastructure, avoids significantly increasing the guest attack surface.

Implement

All guest commands will use a guest- prefix to distinguish the fact that the commands are handled by the guest. Likewise, events will carry a GUEST_ prefix. Type names (complex types and enums) do not require a special prefix. The following is an example of the proposed guest agent schema:

// qemu/qmp-schema.json
[ 'guest-ping', {}, 'none' ]
[ 'guest-view-file', {'filename', 'str'}, 'none' ]

{ 'GuestType': [ 'linux', 'windows', 'freebsd', 'netbsd', 'openbsd', 'solaris' ] }
{ 'GuestInfo': { 'os-type': 'GuestType', 'os-version': 'str', 'agent-version': 'str' } }
{ 'GUEST_STARTUP': { 'GuestInfo': 'str' } }

In libqmp, the code generated for a guest command is identical to the code generated for a normal command.

Within QEMU, the marshaling code is handled differently. Normally, QEMU only generates