[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API |
Date: |
Sun, 23 Jul 2006 12:39:29 +0100 |
User-agent: |
Mutt/1.4.1i |
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,
Daniel P. Berrange <=
[Qemu-devel] Re: Re: QEMU GUI-Frontend based on Libvert API, Anthony Liguori, 2006/07/23
Re: [Qemu-devel] Re: Re: QEMU GUI-Frontend based on Libvert API, James Olsen, 2006/07/24
Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API, Daniel Veillard, 2006/07/26