[libvirt] [virt-tools-list] [PATCH DISCUSSION ONLY] Add inspection thread to virt-manager.

[Daniel P. Berrange]

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 :|