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

[Pino Toscano]

On Sunday, 20 September 2020 22:09:54 CEST Cole Robinson wrote:
> 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.

First of all: how often does this case happens? My guess is that this
is common on older distros, when you osinfo-db is not up-to-date, and
you are trying to install a very recent guest. Are there other notable
or happening often cases?

> 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

So either of
  --os-variant generic
  --os-variant detect=off,name=generic
will disable the detection and use "generic" (i.e. no specific OS),
right?

> (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.)

Right: IMHO we need to provide more accurate devices for different
architectures in osinfo-db, and slowly move virt-manager to rely on
them rather than hardcoding architecture checks. This is a different
discussion though :)

> 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

Makes sense, maybe setting 2022 as years when perform this switch?

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

There are certainly people who install Windows like this, and even the
unattended installation works (registration included). The thing is,
defaulting to virtio only works for Linux guests:
- Windows guests: you really want to use the latest available version
  of the server/desktop Windows you have, i.e. currently win10 for
  desktop and win2k19 for server; sadly there is no automated way to
  know that
- other OSes: virtio may not be implemented at all, so you really want
  generic for them

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

Yes, I agree with this. Sadly I don't have a good answer either,
otherwise I'd had proposed it already.

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

This is IMHO split between "there is no latest version of the distro
I want" and "there is not the distro I want".
The former can be easily solved by picking the latest version
available, which is good enough usually. The problem is that there is
no automated way to do that (see [1]), so ATM we cannot present a list
of "latest releases of distros" for users to choose from.
The latter is, well, basically the open question of the email.

[1] https://gitlab.com/libosinfo/libosinfo/-/issues/6

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

A similar thing was recently mentioned by Dan in a osinfo-db ticket for
illumos:
https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/194#note_397864049

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

While I can see the reasons behind this, I'm not totally convinced
about them in osinfo-db. An alternative possibility would be to have
them locally in virt-manager only though.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20200922/7dc7d0f1/attachment.sig>