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
Attachment:
signature.asc
Description: This is a digitally signed message part.
