Red Hat Bugzilla – Full Text Bug Listing
|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:||NEW ---||QA Contact:|
|Version:||unspecified||CC:||berrange, crobinso, gczarcinski, hbrock, rvokal, virt-maint, xen-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Bill Nottingham 2009-07-01 11:46:27 EDT
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 10:53:00 EDT
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 17:48:58 EDT
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 Berrange 2009-07-03 18:05:50 EDT
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 07:48:55 EDT
Okay, moving upstream
Comment 6 Cole Robinson 2016-03-20 18:56:05 EDT
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.