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
