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

[Cole Robinson]

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.

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

Thanks,
Cole