Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QEMU GUI-Frontend based on Libvert API
Hi All, I know there's been several thread discussions regarding GUI-Frontend for QEMU and there already exist some projects that offers GUI for QEMU. But, recently, I've come to learn about an open source project called libvert which is actively being developed at http://www.libvirt.org. Below is a short description and the goal for this project: *(Note: The content below was taken from the following link: http://www.devx.com/amd/Article/31817/1763) libVirt, an open source project stewarded and driven by Red Hat, with contributions from Red Hat, IBM, Novell, Bull, VMware, and others. 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). The goal of libVirt is to provide the lowest possible generic and stable layer to manage VMs running on a machine. To accomplish this goal, libVirt will not try to be all things related to virtualization—instead libVirt will provide consistent and stable APIs to enable other tools to be built and used on top of the libVirt layer. Although the premise for libVirt seems pretty simple, the project has turned out some very mature features and tools, including: * Local administration tools—including a shell (virsh), a GNOME application, and a GNOME monitoring applet. * Plenty of control interfaces—shell scripting, Python and Perl bindings, and robust APIs. * Monitoring interfaces—feeding stats and states to applications, daemons, and the API hooks for other applications to utilize * A robust policy framework—enabling complex policies to monitor, control, and correct domains running on the node. * An XML structure for defining domains—portable, easily parsed, and human readable. A big advantage of libVirt's vendor-neutral stance is that you can define a framework for your VMs, applications, and policies that will run with most of the popular VMMs (XEN or QEMU). Code once—a somewhat unique aspect in the development space. 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. I must admit here, that I do have a personal interest and motivation for developing such a project - The reasons are: I am planning to launch (soon) an open source community web site called OpenSourceDemo.com (OSD)... The site will make available DEMO's for some of the most popular Free Open Source Software applications. The site will make available 2 types of demo's. One type of demo will be online web based demos. The other will come in the form of a "Software Appliance" which is a pre-built and pre-configured software that is packaged in a single image file that can be downloaded and run on users local PC using a product like VMware Player or QEMU. Initially, before learning much about QEMU, I had plans to offer VMware Player to users on the site to run and demo the appliances. However, since the site promotes open source, I would prefer to offer an open source alternative to VMware Player and think QEMU is the best option. However, I need to have a GUI product that would make it easy for users to adopt and use - especially those that are already use to VMware product. It is this idea that has motivated me to start a GUI project that supports QEMU. And, I would like to leverage the LibVirt project for this. I invite and welcome developers from the list who would have interest to contribute in the development of a QEMU GUI based on the libVirt API. Evan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel