Following on from this I submitted a linux2020 entry to osinfo-db: https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/237 Thanks, Cole On 9/20/20 4:09 PM, Cole Robinson wrote: > 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 > - Cole
