From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G4cJ9-0005nL-Kx for qemu-devel@nongnu.org; Sun, 23 Jul 2006 07:39:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G4cJ6-0005mo-W1 for qemu-devel@nongnu.org; Sun, 23 Jul 2006 07:39:39 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4cJ6-0005ml-PU for qemu-devel@nongnu.org; Sun, 23 Jul 2006 07:39:36 -0400 Received: from [66.187.233.31] (helo=mx1.redhat.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G4cJx-0007os-JP for qemu-devel@nongnu.org; Sun, 23 Jul 2006 07:40:29 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6NBdVC5012197 for ; Sun, 23 Jul 2006 07:39:31 -0400 Received: from file.surrey.redhat.com (file.surrey.redhat.com [172.16.10.4]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6NBdUnG011529 for ; Sun, 23 Jul 2006 07:39:30 -0400 Received: (from berrange@localhost) by file.surrey.redhat.com (8.13.1/8.13.1/Submit) id k6NBdTr8008440 for qemu-devel@nongnu.org; Sun, 23 Jul 2006 12:39:29 +0100 Date: Sun, 23 Jul 2006 12:39:29 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API Message-ID: <20060723113929.GB4412@redhat.com> References: <44C11ED6.3090006@opensourcedemo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: "Daniel P. Berrange" , 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 On Fri, Jul 21, 2006 at 02:21:21PM -0500, Anthony Liguori wrote: > On Fri, 21 Jul 2006 14:37:10 -0400, Evan Paul wrote: > > > > The libVirt project is a community-sponsored project that aims to bring > > more simplicity and standards to the Linux VM world. At its core, > > libVirt is a C toolkit that provides interaction with virtualization > > capabilities of the Linux operating system (and those related to Linux). > > You make it sound so professional :-) > > > Currently, there is a project called Virt-Manager that is building a > > GUI-Frontend using the LibVirt API. More info on the Virt-Manager > > project can be found here: > > http://people.redhat.com/berrange/virt-manager/ > > > > For me, I personally like the idea and focus of libVirt project and > > would like to see if any QEMU developers from the list would have an > > interest to team up with me to develop an open source GUI-Frontend based > > on the LibVirt API. > > Why would you create a second GUI interface when virt-manager already > exists as a libvirt GUI front-end? > > As far as I know, the big hurdle for QEMU and libvirt right now is not any > GUI aspects (VNC would work just fine). It's interacting with QEMU. Xen > provides an XML-RPC interface to managing instances whereas QEMU only > really provides the monitor interface. Of course, there's still a bit of > work to do before libvirt uses actually uses that interface (it currently > uses the older S-Expression/HTTP interface). Basically, there's quite a > bit of work to do in libvirt before you could even start writing a GUI for > QEMU. I'd actually go so far as to say - if you added support for QEMU in libvirt the 'virt-manager' GUI would 'just work' without need for any further coding. This is one of the major points of libvirt - you can have multiple backends for different virtualization technologies, but your end user applications never have to really care (much) about the differences since they are presented a consistent API. The only real differences will be in the range of virtual hardware devices exposed by each backend & what config options they allow. > I have toyed around with the idea of writing an XML-RPC front-end to QEMU > (with the idea of bridging the gap for libvirt). DV also had a patch > floating around to add a socket management interface to QEMU (although now > there is a TCP character device so I presume his patch is unnecessary). If there was a way to enumerate all running QEMU instances on a machine in a reasonably fast manner (ie, not reading every single /proc/PID entry), the existing QEMU monitor interface exposes enough functionality to support most of libvirt API. So the main questions are how to enumerate QEMU instances & how to connect to the monitor - UNIX, TCP, or XML-RPC are all possible options with plus/minuses. UNIX is nice because you can manage security with simple file permissions on the socket. TCP/XML-RPC is nice because you can manage VMs remotely - but you'd need to do some kind of sensible auth scheme in remote case - unlike Xen which allows anyone to connect :-( Regards, Dan, -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|