Hi Dor,
I appreciate your comments. The GUI interface would be an attempt to give
KVM the same kind of features that some of the commercial virtualization
products provide. A single GUI interface to manage multiple virtual host
systems. The goal would be to create a tightly integrated solution that
would allow management of even the most subtle KVM features, options, and
functions. The exposure of the host / guest communication facilities would
be a good example. It might also be interesting to take a look at
providing a guest utility library as well. I'm very excited about the KVM
project and the tremendous potential it opens up in virtualization. It's
really got the gears in my head turning.
Thanks,
-G
"Dor Laor" <[EMAIL PROTECTED]>
09/04/2007 02:38 AM
To
<[EMAIL PROTECTED]>, <kvm-devel@lists.sourceforge.net>
cc
Subject
RE: [kvm-devel] libqemu => libkvm?
Hi Folks,
I've been spending some time playing around with KVM and I am starting to
become interested in making a contribution to the project. I'm considering
the idea of writing a library interface to libqemu in a KVM context. I am
aware of libvirt, but that isn't what I'm thinking here. This lib would be
very specific to KVM. I have been poking around in the source a bit and it
seems like it would be possible. Before I go further, I thought I would
ask a few questions. I would also appreciate any and all opinions on the
subject.
1. Is anyone already thinking about , or actually doing this?
That's a real interesting idea. Actually this is the first time I
discovered people use libqemu
apart from qemu itslef. We didn't thought about this yet.
2. Does this sound useful?
It does create some interesting VM-process merges although a regular VM
has monitor interface
or dbus interface so many actions can be done by tcp to qemu.
Actually there is work in progress to add dbus interface to qemu. I might
not fit every thing but can help
for some cases.
3. Is the libqemu API stable enough at this point to write code against?
I believe KVM triggers some changes to it.
4. Can anyone see any immediate road blocks to doing this?
Except for exposing the same api, no.
This would probably also include a cross platform GUI interface at some
point. This interface would be specific to KVM and the subtle nuances that
make it unique. I've been looking for a good excuse to use FLTK on a
project anyway ;-)
Why do you need a gui? What's your application/plan for it?
Thanks for your consideration,
-G
Regards, Dor
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
