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