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

[Cole Robinson]

Following on from this I submitted a linux2020 entry to osinfo-db:

https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/237

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