qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joe Lee
Subject: Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
Date: Fri, 21 Jul 2006 15:58:41 -0400
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

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
address@hidden
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]