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

[Cole Robinson]

On 9/22/20 11:53 AM, Pino Toscano wrote:
> 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?
> 

It was worse in the past for sure, osinfo-db was much more sparse 2
years ago. Still, the main places I see it historically, is people
installing pre-release distros, or new distro variants that aren't yet
represented in osinfo-db: special RHEL variants, more recently
Fedora/RHEL CoreOS.

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

`--os-variant generic` and `--os-variant name=generic` are identical,
and both will skip detection. detect=on isn't the unconditional default,
it's more that if the user doesn't specify anything, the default is
`--os-variant detect=on,name=generic`, otherwise those options are all
empty/false.

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

Agreed

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

We could base it on RHEL/Centos release. If/when virt-install 3.0.0 is
in a centos8 release, then the next upstream release can make the
change. That may well be 2022

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

Yes that is definitely useful. Kinda like some way of making the
XXX-unknown distro convention an official part of the API.

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

Thanks for the tip. That does sound different to me that I agree it does
not sound like a good idea, it would be like having a meta OS 'redhat'
or something that Fedora/RHEL/CentOS derive from. Doing something like
that as an XML implementation detail to save duplication would be one
thing but leaking that into the API seems weird and ambiguous.

I think 'linuxDATE' or similar would be reasonably clear as its purpose
and not ambiguous like a plain 'linux' or 'illumous' in the above issue
case. And also harder to misuse

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

Do you have specific objections to adding them to osinfo-db?

We could implement this only in virt-manager/virt-install but I'm
guessing that would take more total work and ongoing maintenance for
something that would be less generally useful. For example maybe
gnome-boxes doesn't need or want this now but I can think of ways they
probably

Thanks,
Cole