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

[Cole Robinson]

FYI I've changed the defaults here upstream now. For x86 HVM VMs, we now
error if an OS is not specified, or detected from install media

https://github.com/virt-manager/virt-manager/commit/26ecf8a5e3e4721488159605afd10e39f68e6382

Here's the complete error message virt-install will print which kinda
covers everything:

```
ERROR
--os-variant/--osinfo OS name is required, but no value was
set or detected.

This is now a fatal error. Specifying an OS name is required
for modern, performant, and secure virtual machine defaults.

If you expected virt-install to detect an OS name from the
install media, you can set a fallback OS name with:

  --osinfo detect=on,name=OSNAME

You can see a full list of possible OS name values with:

   virt-install --osinfo list

If your Linux distro is not listed, try one of generic values
such as: linux2020, linux2018, linux2016

If you just need to get the old behavior back, you can use:

  --osinfo detect=on,require=off

Or export VIRTINSTALL_OSINFO_DISABLE_REQUIRE=1
```


A few things other comments:

* I updated error messages and docs to push users towards the --osinfo
cli naming, which is a newer alias for --os-variant. --osinfo is nicer
naming since it makes it more obvious this value is tied to libosinfo.
--os-variant isn't ever being removed though

* The old behavior was --os-variant detect=on,name=generic. Adding this
to your command line is still a valid workaround. I didn't put this in
the error message though since we should be discouraging usage of
generic. linuxXXXX entries are almost always the better choice here.

* The environment variable is for cases where virt-install is used in CI
jobs or deeply embedded in other tools, where it may be tough to change
the invocation. When the env variable is set we still print the big
error message.

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