Hi virt-tools-list + CCd libosinfo developers too Use of virt-install without a detected guest OS, and without manually specified --os-variant, is a never ending source of bugs and user confusion and poorly performing VM configs. This mail is intended to start a discussion about how to improve that situation. In virt-install 3.0.0 I added some extra options to --os-variant. Examples: * --os-variant detect=on,require=on: detect from media but fail if detection doesn't work * `--os-variant detect=on,name=NAME: detect from media but fall back to os NAME if detection fails The default didn't change though, which is `--os-variant detect=on,name=generic`, with a warning printed if detection fails. 'generic' OS entry is a virt-install creation that basically means 'use libvirts defaults', which are not performant to say the least. (Caveat this is mostly about x86 qemu-using hypervisors. We largely assume the presence of virtio for all arm32/aarhc64/s390x/ppc64/riscv KVM guests even though that's not entirely correct.) For virt-install, the two possible paths forward I see are 1) Default to --os-variant detect=on. Detection failure is fatal. Couple this with a big descriptive error when it fails explaining why this changed, and explaining how to specify a fallback name, with some suggestions how to choose one. Probably wouldn't want to make this change until the new --os-variant options have been around for a release or two 2) Default to --os-variant detect=on,name=<virtio-something>. 'give me virtio' is representative of what most virt-install users want. But this adds some new corner cases, ex if anyone is using virt-install with windows up until now they could get away without specifying a --os-variant and things would generally work, but now if we default to virtio windows out of the box is not going to install. I kinda doubt many people are using virt-install with windows though. I think #1 is the way to go but either case would benefit from some coordination with libosinfo. IMO we don't really have a good story for when users are installing a distro that isn't represented in libosinfo. This applies to virt-manager too. If users are installing 'spanking new exotic distro FOO' and libosinfo can't detect their install media, what OS value should we recommend they use? If they are installing linux there's a 99.9% certainty that the distro is new enough to support all the major virtio devices, so mostly it doesn't matter what distro they choose as long as it's from the past decade. But conveying that is difficult, it's not easily actionable, and it would feel weird to choose ubuntu* when you are installing slackware or something. IMO it would be useful for osinfo-db to have some 'meta' OS entries. Something like linux2018, linux2020, etc. I figure we can probably peg them to roughly match ubuntu LTS device support content. If those existed, we could show them in virt-manager's UI when we don't find any hits for whatever distro name the user starts typing into the search field, like we do for the 'generic' entry. We could even consider pre-selecting them in the virt-manager UI. Similarly we could recommend them in the virt-install error message if detection fails. If they follow a consistent naming pattern, users could probably guess what value they want based on the age of their distro. Thoughts? Other ideas? Thanks, Cole
