Bug 509164

Summary:	RFE: domain: metadata: track VM OS/distro value in the XML
Product:	[Community] Virtualization Tools	Reporter:	Bill Nottingham <notting>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	unspecified	CC:	berrange, crobinso, gczarcinski, hbrock, virt-maint, xen-maint
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-02-06 23:43:32 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	636033

Description Bill Nottingham 2009-07-01 15:46:27 UTC

Description of problem:

When I install a guest, the wizard ask me what sort of guest I'm installing (such as RHEL 5). 

It uses this information to decide how to set up storage devices (among other things.)

However, once that guest is installed, it doesn't use this same information, so when I go to add more storage devices, it offers me options (such as virtio disks) that won't work.

Version-Release number of selected component (if applicable):

virt-manager-0.7.0-5.fc11.x86_64

Comment 1 Mark McLoughlin 2009-07-03 14:53:00 UTC

I agree in principle with "don't offer people options that cannot possibly work", but just because you initially installed RHEL5 in the guest, doesn't mean you haven't updated ... and e.g. RHEL5.3 does support virtio disks

TBH, I think hiding virtio as an option in these cases could make things even more confusing.

Given that, any objections to NOTABUG?

Comment 2 Bill Nottingham 2009-07-03 21:48:58 UTC

I could see hiding ones that would never work (virtio on ancient windows, or something silly like that.) 

But that might be significant effort.

Comment 3 Daniel Berrangé 2009-07-03 22:05:50 UTC

The core problem here is that no part of the virt stack actually tracks the OS type post-install. So we have no permanent record that this guest were installed with RHEL5 or any other OS.

For the VMWare driver, libvirt is going to have to start tracking this info, since its a compulsory part of the vmware config info. So there would be a case to extend this to KVM and other libvirt drivers. At which time virt-manager would have the ability to simplify things, or at least suggest better defaults. No ETA on this though, so this bug should probably be re-assigned to upstream

Comment 4 Mark McLoughlin 2009-08-07 11:48:55 UTC

Okay, moving upstream

Comment 6 Cole Robinson 2016-03-20 22:56:05 UTC

Not positive if this is something we should still do. We have the custom metadata support which tools like gnome-boxes use to track the VM's os value, but it would be nice if we had a standard field for it.

Or maybe the answer is we just standardize among apps that there's a specific tag name for tracking a  libosinfo short-id value.

Comment 7 Cole Robinson 2019-02-06 23:43:32 UTC

Rather than officially tracking this in libvirt XML, apps have decided to use libvirt custom metadata XML with a schema shared for libosinfo users. You can see the thread here:

https://www.redhat.com/archives/libosinfo/2018-September/msg00003.html