qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RFC][PATCH 00/10] virtagent: host/guest RPC communicat


From: Andrew Beekhof
Subject: [Qemu-devel] Re: [RFC][PATCH 00/10] virtagent: host/guest RPC communication agent
Date: Sat, 23 Oct 2010 13:31:41 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Thunderbird/3.1.4

On 10/22/2010 08:45 PM, Michael Roth wrote:
This set of patches is meant to be applied on top of the Virtproxy v1 patchset.

OVERVIEW:

There are a wide range of use cases motivating the need for a guest agent of 
some sort to extend the functionality/usability/control offered by QEMU. Some 
examples include graceful guest shutdown/reboot and notifications thereof, 
copy/paste syncing between host/guest, guest statistics gathering, file access, 
etc.

Ideally these would all be served by a single, easilly extensible agent that 
can be deployed in a wide range of guests. Virtagent is an XMLRPC server 
integrated into the Virtproxy guest daemon and aimed at providing this type of 
functionality.

This code is very rough, and I'll to document most of the bugs/shortcomings 
we're aware of in this version of the patchset. The main goal of this RFC to 
get feedback on the types of core functionality we would need in an agent of 
this sort, as well as feedback on the general approach/architecture implemented 
here. Any feedback is greatly appreciated however.

To start off this discussion, there have been some recent posts about how much 
an agent of this sort overlaps with the goals of the Matahari project 
(https://fedorahosted.org/matahari/). While both of these approaches are at 
least *feasible*, our use cases require


the ability to deploy to guests which may not support virtio-serial, which 
currently rules Matahari out.

Possibly there has been some miscommunication, Matahari does not require virtio-serial.

It will be possible to configure Matahari to use virtio-serial if it exists, but like Virtproxy it can also be used over a regular IP network (yes, its transparent to clients too).

-- Andrew

This support could be added however: the virtproxy layer used by this agent 
actually lends itself to extending such support to other agents/services, or a 
more direct approach could be taken in adding support for isa-serial.

The question that remains however is one of scope. This agent is intended 
purely as a means to extend qemu's abilities to perform hypervisor-specific 
work, whereas Matahari aims to extend general system management capabilities to 
guests (please correct me if I'm oversimplifying). Virtagent cannot meet 
Matahari's goals, whereas Matahari technically can meet Virtagent's. My 
contention however is that the qemu-specific scope/API and shared code base 
with a more closely integrated agent will provide a more expedient route to 
functional improvements to qemu, while still allowing for the additional 
functionality/management capabilities provided by something like Matahari.

DESIGN:

There are actually 2 RPC servers:

1) a server in the guest integrated into the Virtproxy guest daemon which 
handles RPC requests from QEMU
2) a server in the host (integrated into the Virtproxy host daemon, which we 
plan to integrate directly into qemu) to handle RPC requests sent by the guest 
agent (mainly for handling asynchronous events reported by the agent).

At the Virtagent level, communication is done via standard RPCs (HTTP/TCP 
between host and guest). Virtproxy transparently handles transport over a 
network or isa/virtio serial channel, allowing the agent to be deployed on 
older guests which may not support virtio-serial.

Currently there are only 2 RPCs implemented for the guest server (getfile and 
getdmesg), and 0 for the host. Additional RPCs can be added fairly easily, but 
are dependent on feedback from here and elsewhere. ping/status, shutdown, and 
reboot are likely candidates (although the latter 2 will likely require 
asynchronous notifications to the host RPC server to implement reliably).

EXAMPLE USAGE:

The commandline options are a little convoluted right now; this will addressed 
in later revisions.

  - Configure guest agent to talk to host via virtio-serial
     # start guest with virtio-serial. for example (RHEL6s13):
     qemu \
     -device virtio-serial \
     -chardev socket,path=/tmp/test0-virtioconsole.sock,server,nowait,id=test0 \
     -device virtconsole,chardev=test0,name=test0 \
     -chardev socket,path=/tmp/test1-virtio-serial.sock,server,nowait,id=test1 \
     -device virtserialport,chardev=test1,name=test1 \
     -chardev socket,path=/tmp/test2-virtio-serial.sock,server,nowait,id=test2 \
     -device virtserialport,chardev=test2,name=test2 \
     -monitor stdio
     ...
     # in the host:
     ./qemu-vp -c unix-connect:/tmp/test2-virtio-serial.sock:- \
               -o virtagent:/tmp/virtagent-guest-client.sock:-
     # in the guest:
     ./qemu-vp -c virtserial-open:/dev/virtio-ports/test2:- -g
     ...
     # monitor commands
     (qemu) agent_viewdmesg
     [139311.710326] wlan0: deauthenticating from 00:30:bd:f7:12:d5 by local 
choice (reason=3)
     [139323.469857] wlan0: deauthenticating from 00:21:29:cd:41:ee by local 
choice (reason=3)
     ...
     [257683.375646] wlan0: authenticated
     [257683.375684] wlan0: associate with AP 00:30:bd:f7:12:d5 (try 1)
     [257683.377932] wlan0: RX AssocResp from 00:30:bd:f7:12:d5 (capab=0x411 
status=0 aid=4)
     [257683.377940] wlan0: associated

     (qemu) agent_viewfile /proc/meminfo
     MemTotal:        3985488 kB
     MemFree:          400524 kB
     Buffers:          220556 kB
     Cached:          2073160 kB
     SwapCached:            0 kB
     ...
     Hugepagesize:       2048 kB
     DirectMap4k:        8896 kB
     DirectMap2M:     4110336 kB

KNOWN ISSUES/PLANS:
  - the client socket that qemu connects to send RPCs is a hardcoded filepath. 
This is unacceptable as the socket is channel/process specific and things will 
break when multiple guests are started.
  - capability negotiation will be needed to handle version/architecture 
differences.
  - proper channel negotiation is critical to avoiding hung monitors and such 
when a guest reboots or the guest agent is stopped for whatever reason. 
additionally, a timeout may need to be imposed on the amount of time the http 
read handler can block the monitor.
  - additional host-to-guest RPCs as well as asynchronous notifications via 
guest-to-host RPCs for events such as shutdown/reboot/agent up/agent down
  - switch all RPC communication over to non-blocking/asynchronous read/write 
callbacks to avoid deadlocks.

  Makefile            |    2 +-
  Makefile.target     |    2 +-
  configure           |   25 ++++
  hmp-commands.hx     |   32 +++++
  monitor.c           |    1 +
  qemu-vp.c           |  119 +++++++++++++++--
  qerror.c            |    4 +
  qerror.h            |    3 +
  qmp-commands.hx     |   68 +++++++++
  virtagent-common.c  |  381 +++++++++++++++++++++++++++++++++++++++++++++++++++
  virtagent-common.h  |   63 +++++++++
  virtagent-daemon.c  |  216 +++++++++++++++++++++++++++++
  virtagent-daemon.h  |   21 +++
  virtagent.c         |  298 ++++++++++++++++++++++++++++++++++++++++
  virtagent.h         |   32 +++++
  virtproxy-builtin.c |   30 ++++
  16 files changed, 1286 insertions(+), 11 deletions(-)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]