On Mon, Apr 18, 2011 at 06:40:31PM -0400, Cole Robinson wrote:
On 04/18/2011 06:12 PM, Richard W.M. Jones wrote:
On Mon, Apr 18, 2011 at 05:50:01PM -0400, Cole Robinson wrote:
First, thanks a lot for the patch! I'm sure everyone will be glad to see libguestfs integration in virt-manager.
[This patch is incomplete and just for discussion]
Using libguestfs inspection[1], we can find out a lot about a virtual machine, such as what operating system is installed, the OS version, the OS distro, the hostname, the (real) disk usage, what apps are installed, and lots more. It would be nice if virt-manager could use this information: for example we could change the generic "computer" icon into a Windows or Fedora logo if Windows or Fedora was installed in the virtual machine.
That icon bit was originally intended for the current design, but since we've never really tracked OS info after install time, it never came about.
Particularly for OS type/version tracking, I think we need a few things:
- Everything standardize on some naming scheme, ideally libosinfo (though nothing is using it yet :/ ). libosinfo could also distribute the OS icons
We sort of got bored of waiting for that train. We have a primitive but rather effective system in libguestfs, which I explain at the end of this email.
Yeah I hear you on that. However, for the libguestfs OS value to really be useful for us in virt-manager, we have to map it to the virtinst osdict which informs us of all the preferred device defaults (like virtio, usb tablet, virtio console, etc.). Which means more energy that would be better spent on getting libosinfo integrated.
Yep, it is way overdue to integrate that work.
- Libvirt domain XML schema is extended with a field to track the installed OS. For most libvirt drivers this would just be metadata (vmware/esx the exception). Even though the data might be out of date if the guest is upgraded, I think it has become clear that there is a lot of value in tracking this in XML.
Yes, I agree. This also solves the persistence problem.
It's a bit of a shame that the <description> field in the libvirt XML isn't structured, at least so that different applications could store their own data there without it being trampled upon by users or other applications. (CC'd to libvir-list in case they have any thoughts about that).
I think <description> is fine the way it is, there is always going to be a use case for an end user freeform field like that. But there is certainly a case for a similar field (or multiple fields) for recording more metadata, possibly for use by apps. Maybe something with XML namespaces.
We could easily define a <metadata> element and a bunch of specific fields within it, and also setup some way to parse & preserve app specific metadata there. The main issue is finding a way to support it for all hypervisors. For QEMU, LXC, UML & XenLight we can do it because the master config file is our XML. For XenD, VMWare, VirutalBox we use the native config file. If they have a generic description field, we could steal that and store the <metadata> XML in that and re-parse. Or something. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|