On 9/21/20 4:01 PM, Charles Arnold wrote: > On Sun, 2020-09-20 at 16:09 -0400, 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 > > +1 > >> >> 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. > > It is hard to know how many customers use windows VMs but I know for a > fact (from bug reports) that there are some. > >> >> >> 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. > > There is (or was) some code in virt-manager that when a disto is > identified by name but the particular version is not found in libosinfo > it falls back to using the newest definition of that distro in the > database. > Yes we have some heuristics for this. In time they should go away though because the -unknown pattern in libosinfo should handle it, at least for .treeinfo using distros. >> >> 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. > > This is much better than 'generic' which never works Great, thanks for the feedback - Cole
