virt-install: changing default --os-variant behavior

[Cole Robinson]

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