Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API

2006-07-23 Thread Evan Paul

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

2006-07-21 Thread Evan Paul

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