qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC][PATCH v5 00/21] virtagent: host/guest RPC communi


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC][PATCH v5 00/21] virtagent: host/guest RPC communication agent
Date: Fri, 10 Dec 2010 10:03:15 +0000

On Thu, Dec 9, 2010 at 8:45 PM, Michael Roth <address@hidden> 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



reply via email to

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