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 -=| _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
