From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LC9iE-0002Rl-Um for qemu-devel@nongnu.org; Mon, 15 Dec 2008 04:26:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LC9iC-0002QX-1M for qemu-devel@nongnu.org; Mon, 15 Dec 2008 04:26:02 -0500 Received: from [199.232.76.173] (port=34715 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LC9iB-0002QT-PJ for qemu-devel@nongnu.org; Mon, 15 Dec 2008 04:25:59 -0500 Received: from mx2.redhat.com ([66.187.237.31]:33894) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LC9iB-0002B4-BS for qemu-devel@nongnu.org; Mon, 15 Dec 2008 04:25:59 -0500 Date: Mon, 15 Dec 2008 11:25:52 +0200 From: Dan Kenigsberg Subject: Re: [Qemu-devel] [PATCH] Vmchannel PCI device. Message-ID: <20081215092551.GC6957@redhat.com> References: <20081214115027.4028.56164.stgit@dhcp-1-237.tlv.redhat.com> <20081214131247.GS5555@redhat.com> <49455B5E.8080504@codemonkey.ws> <20081214193735.GA7215@redhat.com> <49458E24.5090609@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49458E24.5090609@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kvm@vger.kernel.org, Gleb Natapov On Sun, Dec 14, 2008 at 04:52:20PM -0600, Anthony Liguori wrote: > Gleb Natapov wrote: >> On Sun, Dec 14, 2008 at 01:15:42PM -0600, Anthony Liguori wrote: >> I don't know why do you think that we are going to use that for >> closed >> code or something. It will be used by libvirt and it is open source last >> I checked. >> > > For what? > > vmchannel was developed for SPICE, is this not right? That's where my > assumption comes from. If there's another use case, please describe it. Our management system uses vmchannel to communicate with an agent running on the guest. We use this agent to collect information about the guest OS: e.g., installed applications, who's logged in, whether anything's running, or the guest is rebooting. The agent is capable of performing operations on the guest, too. We use this to log a user in (for single sign-on), to log a user out before migrating to file, to renew the guest's dhcp lease if the guest is migrated to another subnet, to name a few uses. Dan.