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

[Evan Paul <paulev@gmail.com>]

Daniel P. Berrange wrote:
> 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,
>   
Dan wrote:
> 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 think this is great and hope many developers working on QEMU-GUI can 
put some effort in adding the support
for QEMU.

Dan, I have this question regarding virt-manager: Does it currently 
support actually creating VM. I see features where it provides the 
ability to configure stuff but saw nothing about creating VM.
Also, does virt-manager have support to actually install/update a 
particular VMM like XEN or QEMU (when support is avaialble) from the GUI 
interface itself. If not, that would be a good feature where users can 
download a given file within the GUI and some script would auto install 
and set it up.

Regards,
Evan