Re: [Qemu-devel] [RFC][PATCH v5 00/21] virtagent: host/guest RPC communication agent
On Thu, Dec 9, 2010 at 8:45 PM, Michael Roth mdr...@linux.vnet.ibm.com wrote: On 12/08/2010 04:10 AM, Stefan Hajnoczi wrote: What concrete use-cases are there? * Reboot support on x86. A QMP command can invoke guest-initiated reboot via virtagent. * ? * viewfile The ability to do a quick peek at guest stats via, say, /proc, is a use case that seems to be fairly generally desirable. It's what essentially started all this work, actually. That's also why I think a simple/limited viewfile RPC for relatively small text files is warranted regardless of whatever approach we end up taking for handling large/binary file transfers. * getdmesg Really useful for trouble-shooting things like soft-lockups. * ping Heartbeat monitoring has also been a fairly re-occurring approach to identifying potential problems in our cloud, and it's not even something we're capable of accomplishing in a production environment due to having limited network access to the guests. Being able to do it without relying on custom/network-based daemons would be pretty useful. * exec (planned) Internally and externally I've seen interest in guest-initiated snapshots, but that would tie into exec or some other, higher-level, RPC, which isn't yet well-defined. * copyfile (planned) Nothing solid, but I think it's generally desirable. Quick access to coredumps and such would be useful. Lots of discussion on how to implement this and I think we have some good potential approaches to adding this soon. * writefile (planned) Nothing solid. But guest activation is probably a big potential use case for this one. Managing various guest kernel params is another. Another would be deploying custom scripts to run via exec. Perhaps getfile and putfile as names? Will virtagent be extensible by host administrators or end-users? For example, can I drop in a custom command to collect statistics and invoke it across VMs on my hosts? Do I need to recompile QEMU and/or the virtagent daemon? writefile + exec would probably be the best way to achieve this. I don't think there are any plans to make the supported set of RPCs pluggable/extendable. Thanks for explaining this, I think this is an important aspect of virtagent. Users will want to take advantage of an always-available host-guest management transport. There should be a clear scope defined for virtagent. For example users might include backup, monitoring, and inventory (making sure installed software is up-to-date) software. I imagine just how flexible and easy to use will be controversial because some people may feel users should use this channel into the VM carefully and only in situations where other remote access methods are not suitable (e.g. ssh, etc). If there is a flexible interface from the start then new use-cases can be implemented without modifying QEMU/virtagent source code and updating guests. Stefan
Re: [Qemu-devel] [RFC][PATCH v5 00/21] virtagent: host/guest RPC communication agent
On Thu, Dec 9, 2010 at 9:03 PM, Anthony Liguori aligu...@linux.vnet.ibm.com wrote: On 12/09/2010 02:45 PM, Michael Roth wrote: On 12/08/2010 04:10 AM, Stefan Hajnoczi wrote: On Fri, Dec 3, 2010 at 6:03 PM, Michael Rothmdr...@linux.vnet.ibm.com wrote: These patches apply to master, and can also be obtained from: git://repo.or.cz/qemu/mdroth.git virtagent_v5 Why XML-RPC and not QMP? When I skim through the patch series it seems like much of the work being done is very similar to QMP. It does, actually, more than I realized. In terms of data encapsulation I don't see why we couldn't use QMP/JSON for at least the current set of RPCs. XMLRPC does support a wider range of data types however, such as nestable arrays and structs, and set-precision numerical types like 32 and 64-bit ints/floats, which may prove useful for future lower level interfaces. 1) XML-RPC is more widely supported than QMP (as there is zero support for QMP outside of QEMU and libvirt) True, but the current design doesn't lend itself to custom agents at the XML-RPC level. Therefore using a standard protocol doesn't win anything - it would have been more useful for QMP actually. 2) The target of this work is for guest agents Not sure what this means. 3) QMP does not support bidirectional RPC messages. Right. QMP has commands, responses, and asynchronous events so the client and server are two different roles (asymmetric). I hadn't though through the details and this suggests shoehorning QMP in as the agent protocol would be ugly. 4) The RPC mechanism is a minor part of virt-agent so ultimately, it kind of doesn't matter. The RPC messages themselves are what's important. Getting the design and features of virtagent right is key. But we still need to maintain the code, that's why I ask about reusing what we've got. Stefan
Re: [Qemu-devel] [RFC][PATCH v5 00/21] virtagent: host/guest RPC communication agent
On 12/09/2010 02:45 PM, Michael Roth wrote: On 12/08/2010 04:10 AM, Stefan Hajnoczi wrote: On Fri, Dec 3, 2010 at 6:03 PM, Michael Rothmdr...@linux.vnet.ibm.com wrote: These patches apply to master, and can also be obtained from: git://repo.or.cz/qemu/mdroth.git virtagent_v5 Why XML-RPC and not QMP? When I skim through the patch series it seems like much of the work being done is very similar to QMP. It does, actually, more than I realized. In terms of data encapsulation I don't see why we couldn't use QMP/JSON for at least the current set of RPCs. XMLRPC does support a wider range of data types however, such as nestable arrays and structs, and set-precision numerical types like 32 and 64-bit ints/floats, which may prove useful for future lower level interfaces. 1) XML-RPC is more widely supported than QMP (as there is zero support for QMP outside of QEMU and libvirt) 2) The target of this work is for guest agents 3) QMP does not support bidirectional RPC messages. 4) The RPC mechanism is a minor part of virt-agent so ultimately, it kind of doesn't matter. The RPC messages themselves are what's important. Regards, Anthony Liguori QMP can be fairly trivially extended for some of these things, but JSON is a limiting factor in some cases. We can't maintain strong typing of data across the transport for instance, since JSON only allows for a generic number type, whereas with XMLRPC we can explicitly specify the machine representation. But whether this really matters is hard to say with the limited set of RPCs we have right now. In terms of using QMP all the way through...that sounds really cool, but with the bi-directional client/server data being multiplexed over a single channel, and increased potential for weird states resulting from guest/guest agent restarts, there's a need for some additional synchronization that might end up being fairly intrusive/undesirable to work into QMP. What concrete use-cases are there? * Reboot support on x86. A QMP command can invoke guest-initiated reboot via virtagent. * ? * viewfile The ability to do a quick peek at guest stats via, say, /proc, is a use case that seems to be fairly generally desirable. It's what essentially started all this work, actually. That's also why I think a simple/limited viewfile RPC for relatively small text files is warranted regardless of whatever approach we end up taking for handling large/binary file transfers. * getdmesg Really useful for trouble-shooting things like soft-lockups. * ping Heartbeat monitoring has also been a fairly re-occurring approach to identifying potential problems in our cloud, and it's not even something we're capable of accomplishing in a production environment due to having limited network access to the guests. Being able to do it without relying on custom/network-based daemons would be pretty useful. * exec (planned) Internally and externally I've seen interest in guest-initiated snapshots, but that would tie into exec or some other, higher-level, RPC, which isn't yet well-defined. * copyfile (planned) Nothing solid, but I think it's generally desirable. Quick access to coredumps and such would be useful. Lots of discussion on how to implement this and I think we have some good potential approaches to adding this soon. * writefile (planned) Nothing solid. But guest activation is probably a big potential use case for this one. Managing various guest kernel params is another. Another would be deploying custom scripts to run via exec. Will virtagent be extensible by host administrators or end-users? For example, can I drop in a custom command to collect statistics and invoke it across VMs on my hosts? Do I need to recompile QEMU and/or the virtagent daemon? writefile + exec would probably be the best way to achieve this. I don't think there are any plans to make the supported set of RPCs pluggable/extendable. Stefan
Re: [Qemu-devel] [RFC][PATCH v5 00/21] virtagent: host/guest RPC communication agent
On 12/08/2010 04:10 AM, Stefan Hajnoczi wrote: On Fri, Dec 3, 2010 at 6:03 PM, Michael Rothmdr...@linux.vnet.ibm.com wrote: These patches apply to master, and can also be obtained from: git://repo.or.cz/qemu/mdroth.git virtagent_v5 Why XML-RPC and not QMP? When I skim through the patch series it seems like much of the work being done is very similar to QMP. It does, actually, more than I realized. In terms of data encapsulation I don't see why we couldn't use QMP/JSON for at least the current set of RPCs. XMLRPC does support a wider range of data types however, such as nestable arrays and structs, and set-precision numerical types like 32 and 64-bit ints/floats, which may prove useful for future lower level interfaces. QMP can be fairly trivially extended for some of these things, but JSON is a limiting factor in some cases. We can't maintain strong typing of data across the transport for instance, since JSON only allows for a generic number type, whereas with XMLRPC we can explicitly specify the machine representation. But whether this really matters is hard to say with the limited set of RPCs we have right now. In terms of using QMP all the way through...that sounds really cool, but with the bi-directional client/server data being multiplexed over a single channel, and increased potential for weird states resulting from guest/guest agent restarts, there's a need for some additional synchronization that might end up being fairly intrusive/undesirable to work into QMP. What concrete use-cases are there? * Reboot support on x86. A QMP command can invoke guest-initiated reboot via virtagent. * ? * viewfile The ability to do a quick peek at guest stats via, say, /proc, is a use case that seems to be fairly generally desirable. It's what essentially started all this work, actually. That's also why I think a simple/limited viewfile RPC for relatively small text files is warranted regardless of whatever approach we end up taking for handling large/binary file transfers. * getdmesg Really useful for trouble-shooting things like soft-lockups. * ping Heartbeat monitoring has also been a fairly re-occurring approach to identifying potential problems in our cloud, and it's not even something we're capable of accomplishing in a production environment due to having limited network access to the guests. Being able to do it without relying on custom/network-based daemons would be pretty useful. * exec (planned) Internally and externally I've seen interest in guest-initiated snapshots, but that would tie into exec or some other, higher-level, RPC, which isn't yet well-defined. * copyfile (planned) Nothing solid, but I think it's generally desirable. Quick access to coredumps and such would be useful. Lots of discussion on how to implement this and I think we have some good potential approaches to adding this soon. * writefile (planned) Nothing solid. But guest activation is probably a big potential use case for this one. Managing various guest kernel params is another. Another would be deploying custom scripts to run via exec. Will virtagent be extensible by host administrators or end-users? For example, can I drop in a custom command to collect statistics and invoke it across VMs on my hosts? Do I need to recompile QEMU and/or the virtagent daemon? writefile + exec would probably be the best way to achieve this. I don't think there are any plans to make the supported set of RPCs pluggable/extendable. Stefan
Re: [Qemu-devel] [RFC][PATCH v5 00/21] virtagent: host/guest RPC communication agent
On Fri, Dec 3, 2010 at 6:03 PM, Michael Roth mdr...@linux.vnet.ibm.com wrote: These patches apply to master, and can also be obtained from: git://repo.or.cz/qemu/mdroth.git virtagent_v5 Why XML-RPC and not QMP? When I skim through the patch series it seems like much of the work being done is very similar to QMP. What concrete use-cases are there? * Reboot support on x86. A QMP command can invoke guest-initiated reboot via virtagent. * ? Will virtagent be extensible by host administrators or end-users? For example, can I drop in a custom command to collect statistics and invoke it across VMs on my hosts? Do I need to recompile QEMU and/or the virtagent daemon? Stefan
[Qemu-devel] [RFC][PATCH v5 00/21] virtagent: host/guest RPC communication agent
These patches apply to master, and can also be obtained from: git://repo.or.cz/qemu/mdroth.git virtagent_v5 CHANGES IN V5: - Dependency on virtproxy dropped, virtagent now handles transport and multiplexing of bi-directional RPCs internally - Removed duplification of qemu_set_fd_handler()-centered i/o code. Support for interacting with objects that use qemu_set_fd_handler() now available to tools via qemu-tools.c and a set of generalized utility functions - Fixed memory leaks in client/monitor functions - Various cleanups CHANGES IN V4: - Added guest agent capabilities negotiation - Added RPC/monitor command to invoke guest shutdown/reboot/powerdown - Added RPC/monitor command to the guest agent - Added guest startup notification (hello) - Added syslog()'ing of guest agent RPCs - Various cleanups CHANGES IN V3: - Integrated virtagent server into virtproxy chardev. Usage examples below. - Consolidated RPC server/client setup into a pair of init routines - Fixed buffer overflow in agent_viewfile() and various memory leaks CHANGES IN V2: - All RPC communication is now done using asynchronous/non-blocking read/write handlers - Previously fork()'d RPC server loop is now integrated into qemu-vp/virtproxy i/o loop - Cleanups/suggestions from previous RFC 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 QEMU and a simple guest daemon, aimed at providing this type of functionality. DESIGN: There are actually 2 RPC servers: 1) a server in the guest agent which handles RPC requests from QEMU 2) a server in the host, integrated into the virtagent chardev, to handle RPC requests sent by the guest agent (mainly for handling asynchronous events reported by the agent). Communication is done via RPCs (XMLRPC/HTTP between host and guest), albeit with a non-standard implementation that allows for multiplexing server/client RPC over a single virtio/isa serial channel. EXAMPLE USAGE: - Configure guest agent to talk to host via virtio-serial # start guest with virtio-serial/virtagent. for example (RHEL6): qemu \ -chardev virtagent,id=test0 \ -device virtio-serial \ -device virtserialport,chardev=test0,name=virtagent0 \ -monitor stdio ... # in the guest: ./qemu-va -c virtio-serial:/dev/virtio-ports/virtagent0:- ... # 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 (qemu) agent_shutdown powerdown (qemu) KNOWN ISSUES/PLANS: - switch to standard logging/trace mechanisms - outstanding requests should be reset if we get a hello notification (this implies guest/guest agent restart) - 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. Makefile |4 +- Makefile.objs |2 +- Makefile.target|2 +- configure | 26 ++ hmp-commands.hx| 80 ++ monitor.c |1 + qemu-char.c| 49 qemu-char.h|4 + qemu-ioh.c | 115 qemu-ioh.h | 34 +++ qemu-tool.c| 25 ++- qemu-va.c | 327 ++ qerror.c |8 + qerror.h |6 + qmp-commands.hx| 164 +++ virtagent-common.c | 759 virtagent-common.h | 66 + virtagent-server.c | 264 ++ virtagent-server.h | 30 ++ virtagent.c| 625 ++ virtagent.h| 48 vl.c | 86 ++- 23 files changed, 2652 insertions(+), 75 deletions(-)
