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

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

[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] Re: QEMU GUI-Frontend based on Libvert API

[Anthony Liguori]

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 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).

My first cut at an XML-RPC front-end for QEMU:

http://hg.codemonkey.ws/qemu-rpcd/

Regards,

Anthony Liguori

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

[Joe Lee]

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 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).
>
> My first cut at an XML-RPC front-end for QEMU:
>
> http://hg.codemonkey.ws/qemu-rpcd/
>
> Regards,
>
> Anthony Liguori
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>   
> Why would you create a second GUI interface when virt-manager already
> exists as a libvirt GUI front-end?
Well, first let me say I am not a programmer and know very little about 
GUI development and their toolkits. But, I have been reading up and 
learning about what's out there. Having said that, I think 
"Virt-Manager" is built using GTK/Glade with Python and I am not quite 
sure if that would meet the requirements to having a cross-platform GUI 
for users. And, something that would offer a native look & feel to the 
OS platform they use.

As mentioned in my previous email, for OpenSourceDemo.com, I'd like to 
make available a VM software product with a GUI that can be used by 
users using windows, linux, and mac-os. Therefore, I don't know if 
GTK/Glade is the best choice for this. If it is, using virt-manager 
would be great!

> Basically, there's quite a bit of work to do in libvirt before you could even start writing a GUI for QEMU.
Hmm, really didn't know how much work would be involved. But, I think it 
would be good to start, if people like the idea of having a QEMU support 
for libVirt. I just think it would great to harrness and leverage the 
work behind libVirt and have support for QEMU. The GUI part would be 
easy to add on.

Also, if it would take a long time to have support for QEMU using 
libvirt, I was wondering if anyone can help me come up with an interim 
solution to have a gui that I can make available on the site. Would 
greatly appreciate the help with this. Ideally, I am looking for a 
solution where the GUI can package QEMU with it. So, as a user installs 
the GUI on there PC it also installs QEMU in one install. This would 
remove the complexity of having to install QEMU and then the GUI. This 
is how I see most of the available GUI that exist work.

Evan

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

[Anthony Liguori]

On Fri, 21 Jul 2006 15:58:41 -0400, Joe Lee wrote:

> Well, first let me say I am not a programmer and know very little about
> GUI development and their toolkits. But, I have been reading up and
> learning about what's out there. Having said that, I think "Virt-Manager"
> is built using GTK/Glade with Python and I am not quite sure if that would
> meet the requirements to having a cross-platform GUI for users. And,
> something that would offer a native look & feel to the OS platform they
> use.

I don't wish to start a flame war, but the idea of a "cross-platform GUI"
is somewhat of a myth.  If nothing else, VMware and Parallels are both
examples of having multiple interfaces optimized for all the platforms
they support.

> As mentioned in my previous email, for OpenSourceDemo.com, I'd like to
> make available a VM software product with a GUI that can be used by users
> using windows, linux, and mac-os. Therefore, I don't know if GTK/Glade is
> the best choice for this. If it is, using virt-manager would be great!

See above.
 
>> Basically, there's quite a bit of work to do in libvirt before you could
>> even start writing a GUI for QEMU.
> Hmm, really didn't know how much work would be involved. But, I think it
> would be good to start, if people like the idea of having a QEMU support
> for libVirt. I just think it would great to harrness and leverage the work
> behind libVirt and have support for QEMU. The GUI part would be easy to
> add on.

Supporting QEMU in libvirt has been on the libvirt TODO list for a while. 
There is quite a lot on the list though.  Feel free to send patches to
libvirt-devel though :-)

> Also, if it would take a long time to have support for QEMU using libvirt,
> I was wondering if anyone can help me come up with an interim solution to
> have a gui that I can make available on the site. Would greatly appreciate
> the help with this. Ideally, I am looking for a solution where the GUI can
> package QEMU with it. So, as a user installs the GUI on there PC it also
> installs QEMU in one install. This would remove the complexity of having
> to install QEMU and then the GUI. This is how I see most of the available
> GUI that exist work.

I posted some patches earlier to implement some of the basic support for
having a GUI bundled with QEMU.  Hopefully that's the first step.

Regards,

Anthony Liguori

> Evan

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

[Linas Žvirblis]

Anthony Liguori wrote:

> I posted some patches earlier to implement some of the basic support for
> having a GUI bundled with QEMU.  Hopefully that's the first step.

As a developer of an old-style GUI front-end [1] to QEMU, I am very
interested in this. Where can I find more information on this? Duplicate
work is the least I want to do.

[1] https://gna.org/projects/qemulaunch/

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

[Anthony Liguori]

On Sat, 22 Jul 2006 00:15:21 +0300, Linas Žvirblis wrote:

> Anthony Liguori wrote:
> 
>> I posted some patches earlier to implement some of the basic support for
>> having a GUI bundled with QEMU.  Hopefully that's the first step.
> 
> As a developer of an old-style GUI front-end [1] to QEMU, I am very
> interested in this. Where can I find more information on this? Duplicate
> work is the least I want to do.
> 
> [1] https://gna.org/projects/qemulaunch/

Look at the archives from the 16th.  Fabrice hasn't said yet whether he
likes this approach.  He also hasn't said he dislikes it though :-)

Regards,

Anthony Liguori

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

[Linas Žvirblis]

Anthony Liguori wrote:

> Look at the archives from the 16th.  Fabrice hasn't said yet whether he
> likes this approach.  He also hasn't said he dislikes it though :-)

I looked trough the GUI part of the patch and this seems to be what I
have always missed in QEMU. Great, really.

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

[Daniel P. Berrange]

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  -=| 

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

[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

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

[Daniel P. Berrange]

On Sun, Jul 23, 2006 at 11:24:22AM -0400, Evan Paul wrote:
> Daniel P. Berrange 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.
> 
> 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.

That is the main capability under development at this time. I expect it
to be in the next release in 3-4 weeks time.

> 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.

Installation of the VMM itself is not a job that is applicable to this
application. There are already perfectly good applications for installing
software on Linux - RPM, Debian PKG, etc. By virtue of having the
virt-manager application installed, packaging dependancies will already
have pulled in Xen / QEMU. Windows of course is a completely different
scenario, but I know there are plenty of packaging tools for dealing
with this on Windows, although I've not used them myself.

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  -=| 

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

[Anthony Liguori]

On Sun, 23 Jul 2006 12:39:29 +0100, Daniel P. Berrange wrote:
>> 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.

The approach I took was to have all qemu spawning be done through a single
daemon that could keep track of running instances.  In the general case, I
don't think there's a way to do it.

Plus, you want to make sure that each instance has the monitor on some
reconnectable interface.

Regards,

Anthony Liguori

> 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,

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

[James Olsen]

Hello everyone,

I've actually tried to do some of these things myself a few months
back. I thought I'd have a daemon or "control" program that would
manage the QEMU instances.

A new instance would be launched by a controller app with a few of
additional parameters. One is a custom window title (I added -t
parameter support, which sets the title of the window). So if you had
two QEMU instances open, the title of one would be "ABC" and the other
would be "XYZ", or whatever you named that virtual computer in the
control app. I found that while I was testing, having more than one
QEMU window with the exact same title is less cumbersome.

Also passed at startup was a unqiue ID string generated by the
control app. It is used to identify that instance. Lastly, the control
app passes it's own process ID. The the QEMU instance contacts the
control app with it's unqiue ID, and then control app knows the
process ID of the instance. From this point on the two processes can
communicate with each other, since they know each other's process ID
and can send messages.

I then tried to modify the SDL sources and QEMU sources to support
receiving messages sent to the window, similar to how (at least
Windows) operating systems work. You can send an app's window a
"minimize", "maximize", etc., messages and the app will respond to
them. So I investigated and found that there is a range of commands
set aside specifically for applications to use (they won't collide
with system messages). So I figured I'd enumerate various QEMU
commands into that region, such as savevm, etc. I then added code to
the SDL/QEMU event loop to process those custom commands and
translate them into the traditional commands and then let the event
loop process the command as normal.

It all worked, but my C/C++ is amateur enough that despite everything
I tried my string parameters came through corrupt a good chunk of the
time. And I've tried allocating my own memory, making copies of the
parameter asap before it was deallocated by the OS, etc., but I never
did get it stabilized before I ran out of time to work on it. The
string is necessary for some commands, such as the loadvm/savevm to
specify the path/filename of the image.

With this support in QEMU, then any controlling application can easily
manage QEMU transparently.

Of course, it doesn't address wrapping controls around the QEMU window
like VMWare does, but a controlling app would only need to implement a
VNC client and map it to a window region or something to that effect,
I suppose. I don't know much about the innerworkings of VNC but it
seems plausible.

--
James
Funny quotes: "There are 10 types of people in the world. 
Those who understand binary, and those who don't." -- Unknown
"A computer once beat me at chess, but it was no match for me at
kick boxing." -- Emo Philips

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

[Daniel Veillard]

On Fri, Jul 21, 2006 at 02:21:21PM -0500, Anthony Liguori wrote:
> 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.

  Yep, it's still in my TODO list. Unfortunately I lost track of QEmu devel
recently, so I may need to restart from scratch it seems, but I really want to
be able to manage QEmu instances from libvirt. What makes me a bit uneasy is
that I didn't really got feedback on my previous patch, so I'm left with
the feeling that having work I do integrated might be hard. The two things
really needed are the possibility to enumerate quickly what qemu instances
are running and then be able to connect to them dynamically to extract
informations or control them. The first one could be done by a centralized
tool (if if you also caught qemu isntances started on from user shell) or 
for example by a list of socket in a dedicated directory, the second one
would preferably an unix socket or an xml-rpc interface but the later means
an XML dependancy and is probably a bit heavy for the task.
  Is it possible to get some sort of agreement that this would be a good
idea to add (then technical issues and patches could be discussed with
reasonable expectation that it would end up being integrated) ?

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/