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

["Daniel P. Berrange" <berrange@redhat.com>]

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