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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list