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
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?
I could see hiding ones that would never work (virtio on ancient windows, or something silly like that.) But that might be significant effort.
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
Okay, moving upstream
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.
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