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

[Cole Robinson]

On 9/21/20 4:01 PM, Charles Arnold wrote:
> 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.
> 

Yes we have some heuristics for this. In time they should go away though
because the -unknown pattern in libosinfo should handle it, at least for
.treeinfo using distros.

>>
>> 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
Great, thanks for the feedback

- Cole