Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
On Fri, Jul 21, 2006 at 02:21:21PM -0500, Anthony Liguori wrote: 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. Yep, it's still in my TODO list. Unfortunately I lost track of QEmu devel recently, so I may need to restart from scratch it seems, but I really want to be able to manage QEmu instances from libvirt. What makes me a bit uneasy is that I didn't really got feedback on my previous patch, so I'm left with the feeling that having work I do integrated might be hard. The two things really needed are the possibility to enumerate quickly what qemu instances are running and then be able to connect to them dynamically to extract informations or control them. The first one could be done by a centralized tool (if if you also caught qemu isntances started on from user shell) or for example by a list of socket in a dedicated directory, the second one would preferably an unix socket or an xml-rpc interface but the later means an XML dependancy and is probably a bit heavy for the task. Is it possible to get some sort of agreement that this would be a good idea to add (then technical issues and patches could be discussed with reasonable expectation that it would end up being integrated) ? Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
On Sun, Jul 23, 2006 at 11:24:22AM -0400, Evan Paul wrote: Daniel P. Berrange 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. 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. That is the main capability under development at this time. I expect it to be in the next release in 3-4 weeks time. 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. Installation of the VMM itself is not a job that is applicable to this application. There are already perfectly good applications for installing software on Linux - RPM, Debian PKG, etc. By virtue of having the virt-manager application installed, packaging dependancies will already have pulled in Xen / QEMU. Windows of course is a completely different scenario, but I know there are plenty of packaging tools for dealing with this on Windows, although I've not used them myself. 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
Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
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
Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
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 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). My first cut at an XML-RPC front-end for QEMU: http://hg.codemonkey.ws/qemu-rpcd/ Regards, Anthony Liguori ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Why would you create a second GUI interface when virt-manager already exists as a libvirt GUI front-end? Well, first let me say I am not a programmer and know very little about GUI development and their toolkits. But, I have been reading up and learning about what's out there. Having said that, I think Virt-Manager is built using GTK/Glade with Python and I am not quite sure if that would meet the requirements to having a cross-platform GUI for users. And, something that would offer a native look feel to the OS platform they use. As mentioned in my previous email, for OpenSourceDemo.com, I'd like to make available a VM software product with a GUI that can be used by users using windows, linux, and mac-os. Therefore, I don't know if GTK/Glade is the best choice for this. If it is, using virt-manager would be great! Basically, there's quite a bit of work to do in libvirt before you could even start writing a GUI for QEMU. Hmm, really didn't know how much work would be involved. But, I think it would be good to start, if people like the idea of having a QEMU support for libVirt. I just think it would great to harrness and leverage the work behind libVirt and have support for QEMU. The GUI part would be easy to add on. Also, if it would take a long time to have support for QEMU using libvirt, I was wondering if anyone can help me come up with an interim solution to have a gui that I can make available on the site. Would greatly appreciate the help with this. Ideally, I am looking for a solution where the GUI can package QEMU with it. So, as a user installs the GUI on there PC it also installs QEMU in one install. This would remove the complexity of having to install QEMU and then the GUI. This is how I see most of the available GUI that exist work. Evan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
