From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBztR-00025k-Nw for qemu-devel@nongnu.org; Sun, 14 Dec 2008 17:56:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBztQ-00025W-51 for qemu-devel@nongnu.org; Sun, 14 Dec 2008 17:56:57 -0500 Received: from [199.232.76.173] (port=41538 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBztP-00025P-Vt for qemu-devel@nongnu.org; Sun, 14 Dec 2008 17:56:56 -0500 Received: from yw-out-1718.google.com ([74.125.46.156]:45735) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBztP-0008BO-KR for qemu-devel@nongnu.org; Sun, 14 Dec 2008 17:56:55 -0500 Received: by yw-out-1718.google.com with SMTP id 6so1112994ywa.82 for ; Sun, 14 Dec 2008 14:56:54 -0800 (PST) Message-ID: <49458F31.8040208@codemonkey.ws> Date: Sun, 14 Dec 2008 16:56:49 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Vmchannel PCI device. References: <20081214115027.4028.56164.stgit@dhcp-1-237.tlv.redhat.com> <20081214131247.GS5555@redhat.com> <49455B5E.8080504@codemonkey.ws> <20081214221346.GA16902@redhat.com> In-Reply-To: <20081214221346.GA16902@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, Gleb Natapov , kvm@vger.kernel.org Daniel P. Berrange wrote: > On Sun, Dec 14, 2008 at 01:15:42PM -0600, Anthony Liguori wrote: > > One non-QEMU backend I can see being implemented is a DBus daemon, > providing a simple bus for RPC calls between guests & host. The main problem with "external" backends is that they cannot easily participate in save/restore or live migration. If you want to have an RPC mechanism, I would suggest implementing the backend in QEMU and hooking QEMU up to dbus. Then you can implement proper save/restore. > Or on > a similar theme, perhaps a QPid message broker in the host OS. Yet > another backend is a clustering service providing a virtual fence > device to VMs. Why not use virtual networking for a clustering service (as you would in real machines). > All of these would live outside QEMU, and as such > exposing the backend using the character device infrastructure > is a natural fit. > If you don't have QEMU as a broker, it makes it very hard for QEMU to virtualization all of the resources exposed to the guest. This complicates things like save/restore and complicates security policies since you now have things being done on behalf of a guest originating from another process. It generally breaks the model of guest-as-a-process. What's the argument to do these things external to QEMU? Regards, Anthony Liguori > Daniel >