From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G4fof-00055p-3Z for qemu-devel@nongnu.org; Sun, 23 Jul 2006 11:24:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G4fod-00055d-7Y for qemu-devel@nongnu.org; Sun, 23 Jul 2006 11:24:24 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4fod-00055F-0y for qemu-devel@nongnu.org; Sun, 23 Jul 2006 11:24:23 -0400 Received: from [64.233.184.227] (helo=wr-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G4fpW-0000dY-2b for qemu-devel@nongnu.org; Sun, 23 Jul 2006 11:25:18 -0400 Received: by wr-out-0506.google.com with SMTP id 71so898627wri for ; Sun, 23 Jul 2006 08:24:22 -0700 (PDT) Message-ID: <44C394A6.4070309@opensourcedemo.com> Date: Sun, 23 Jul 2006 11:24:22 -0400 MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API References: <44C11ED6.3090006@opensourcedemo.com> <20060723113929.GB4412@redhat.com> In-Reply-To: <20060723113929.GB4412@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Evan Paul 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" , qemu-devel@nongnu.org Daniel P. Berrange wrote: > 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, > Dan wrote: > 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 think this is great and hope many developers working on QEMU-GUI can put some effort in adding the support for QEMU. Dan, I have this question regarding virt-manager: Does it currently support actually creating VM. I see features where it provides the ability to configure stuff but saw nothing about creating VM. Also, does virt-manager have support to actually install/update a particular VMM like XEN or QEMU (when support is avaialble) from the GUI interface itself. If not, that would be a good feature where users can download a given file within the GUI and some script would auto install and set it up. Regards, Evan