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. > > 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. - Charles
