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

[Charles Arnold]

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