Description of problem: Missing (current) operating systems in drop-down while creating a new virtual machine in RHEV. Customer would like to see more current operating systems in the drop-down while creating a new machine, such as e.g.: - Debian 8 - FreeBSD 10.3 - Ubuntu 14.04 - Ubuntu 15.04 - Ubuntu 16.04 - SUSE Linux Enterprise Server 12 As of writing, except of RHEL, the list of other Linux operating systems including their hardware profiles is just outdated. Version-Release number of selected component (if applicable): RHEV-3.6.5.3 How reproducible: NA Steps to Reproduce: NA Actual results: Showing RHEL updated versions only Expected results: Should show all RHEL as well as other OS versions. Additional info:
Perhaps we can add to the list something with *, to denote not supported. For example: Debian 7* Ubuntu 19* etc. Not sure it's worth the effort and how long the list would become (what about Solaris X86?!)
Given I am the one who triggered this RHBZ via GSS: It seems that depending on the selected operating system in the drop-down menu, the hardware of the virtual machine is changed - is this correct? Additionally, the operating system selection is also reflected into the virtual machines list view of RHEV-M. Thus the details of the virtual machine say, e.g. "Debian 7" while a Debian 8 is installed...which is confusing. If you worry about the length of the drop-downs, make it two drop-downs for example (similar like in libvirt), e.g. choose the kind of operating system or manufacturer first, then the version. Alternatively make that list for users editable/configurable, so that we can add our own entries for all the operating systems we care about (even they are unsupported). If the webbased framework allows it, you also could make it auto-completing simply.
(In reply to Robert Scheck from comment #4) > Given I am the one who triggered this RHBZ via GSS: It seems that depending > on the selected operating system in the drop-down menu, the hardware of the > virtual machine is changed - is this correct? Additionally, the operating > system selection is also reflected into the virtual machines list view of > RHEV-M. Thus the details of the virtual machine say, e.g. "Debian 7" while > a Debian 8 is installed...which is confusing. Yes, the selection makes a difference in the supportability and configuration (of max values, for example). > > If you worry about the length of the drop-downs, make it two drop-downs for > example (similar like in libvirt), e.g. choose the kind of operating system > or manufacturer first, then the version. Alternatively make that list for > users editable/configurable, so that we can add our own entries for all the > operating systems we care about (even they are unsupported). If the webbased > framework allows it, you also could make it auto-completing simply. Two lists don't make the selection easier, just a two steps approach. Perhaps ability to configure the list by the user is doable. Need to design this.
(In reply to Yaniv Kaul from comment #5) > Yes, the selection makes a difference in the supportability and > configuration (of max values, for example). It also feels like there is different (more vs. less, different types?) virtual hardware assigned when switching the selection. We got here the impression that selecting "Debian 7" for a Debian 8 isn't perfect, but selecting "RHEL 7" is better. Could that be true? > Two lists don't make the selection easier, just a two steps approach. > Perhaps ability to configure the list by the user is doable. Need to design > this. If the list is configurable, would that mean that we also could configure the virtual hardware, max values etc. for this operating system type? The officially supported operating systems should be indeed read-only through.
(In reply to Robert Scheck from comment #6) > (In reply to Yaniv Kaul from comment #5) > > Yes, the selection makes a difference in the supportability and > > configuration (of max values, for example). > > It also feels like there is different (more vs. less, different types?) > virtual hardware assigned when switching the selection. We got here the > impression that selecting "Debian 7" for a Debian 8 isn't perfect, but > selecting "RHEL 7" is better. Could that be true? Possibly, though (without looking at the code and thinking too much) I don't recall an OS that does not support all virtual HW. Perhaps the watchdogs and the less common HW? But all support virtio drivers, for example. > > > Two lists don't make the selection easier, just a two steps approach. > > Perhaps ability to configure the list by the user is doable. Need to design > > this. > > If the list is configurable, would that mean that we also could configure > the virtual hardware, max values etc. for this operating system type? The > officially supported operating systems should be indeed read-only through. I honestly don't know - it's just a thought, brain storming on this, not a design. I think a better approach is to actually understand the use case, rather than design a solution. Note that RHEV strives not to become virt-manager, allowing all the possible tweaks in the world to qemu-kvm, (while making it much 'easier' to choose less-than-optimal settings and harder to properly configure and use).
(In reply to Yaniv Kaul from comment #7) > I honestly don't know - it's just a thought, brain storming on this, not a > design. I think a better approach is to actually understand the use case, > rather than design a solution. > Note that RHEV strives not to become virt-manager, allowing all the possible > tweaks in the world to qemu-kvm, (while making it much 'easier' to choose > less-than-optimal settings and harder to properly configure and use). I know that RHEV doesn't want to get fully featured, but from my point of view I need to be able to either install any OS (be it supported or not) to satisfy customer requirements either with the manually choosen good/optimal settings similar like in virt-manager, or there should be really pre-existing profiles for at least common current OSes (including that they get regulary updated during RHEV lifetime). Additionally, I would like to see the correct OS mentioned in the webbased list/detail views. It would be sad to see that RHEV supports only virtualized RHEL and Microsoft stuff well.
(In reply to Robert Scheck from comment #8) Note the list of OSes and their properties is configurable since 3.3, http://www.ovirt.org/develop/release-management/features/virt/os-info/ Though note that VMs with such new type are then not portable to other oVirt/RHEV setups without modifying the config file there as well There is no difference in most of recent Linux OSes. That's why we haven't added much recently. Perhaps change to Debian 7+? Or just remove that completely...I don't know...the thing is we dont' really want to enumerate all operating systems out there, especially if it doesn't make any difference. And we are not really specifically testing all the Ubuntu/Debian variants either, they are working, but it's best effort only. I'm for adding "+" to those names, and perhaps just get rid of those old obsoleted Ubuntus
(In reply to Michal Skrivanek from comment #9) > Note the list of OSes and their properties is configurable since 3.3, > http://www.ovirt.org/develop/release-management/features/virt/os-info/ > Though note that VMs with such new type are then not portable to other > oVirt/RHEV setups without modifying the config file there as well good to know. However, the configuration doesn't seem to be webbased and not as pretty and shiny as a RHEV admin might expect it ;-) > There is no difference in most of recent Linux OSes. That's why we haven't > added much recently. Perhaps change to Debian 7+? Or just remove that > completely...I don't know...the thing is we dont' really want to enumerate > all operating systems out there, especially if it doesn't make any > difference. And we are not really specifically testing all the Ubuntu/Debian > variants either, they are working, but it's best effort only. > I'm for adding "+" to those names, and perhaps just get rid of those old > obsoleted Ubuntus While adding the "+" is a good idea in general, it no does longer reflect the operating system within the VM anymore (well, it never reflects the OS really, but if using the drop-down properly, it's admin friendly). If this however is the way to go (the "+"), then please definately shrink the long list of RHEL variants, too.
Obsoleting existing entries is problematic, but I believe we have to do that sooner or later. We also try to have entries which matter, so I suppose we can minimize it a bit indeed. Major versions of major OSes could probably remain as such as they are typically different enough (e.g. RHEL 6, RHEL 6, Debian 7, Debian 8), we can squash the unsupported ones into e.g. "RHEL 5 or older" as RHEL 5 is the oldest one which is in active use and is actually tested. Ubuntu should follow similar pattern, though I'm not sure if we need any differentiation as there is no difference in current osinfo files. I'm not sure what's the status of SLES 12 support, need to check that.
We can ditch the old OSes content and replace it with something like os.rhel_3x64.id.value = 15 os.rhel_3x64.obsoletedBy.value = 13 we will still need to keep all pre-existing OS ids so we can properly update it on upgrade and import of exported VMs, but it will still remove a lot of clutter
*** Bug 1457173 has been marked as a duplicate of this bug. ***
Can we get rid of versions/distros in guest list if not very specific reason exists? It's ridiculous how such lists are outdated and iiuc what's mosty in background of such list elements are just aliases, see osinfo.d.
(In reply to Jiri Belka from comment #25) > Can we get rid of versions/distros in guest list if not very specific reason > exists? Apparently there are differences between distros. > It's ridiculous how such lists are outdated and iiuc what's mosty in > background of such list elements are just aliases, see osinfo.d. That's what bug 1432488 would solve, honestly: oVirt would get the OSes from osinfo-db (wich is a noarch package, easily updated in new versions of RHEL), eventually adding extra own details (like the Windows sysprep stuff) only if needed.
Michal: Can you have a look at BZ 1432488, as this one seems the best direction to go. If I understood correctly we would probably need to work with the osinfo providers to get the data in, we need, but I think that would be the easiest approach (+ no need for customers to update/change the properties files). So I would like your opinion on that one, and if this would be a feasible approach. Thanks! Martin
*** Bug 1510009 has been marked as a duplicate of this bug. ***
Unfortunately it's not as easy as it sounds and not really worth the effort, IMO. There are assumptions and architectural choices which are hard to change - e.g. the need to interact with it from J2EE code, I do not believe there are any production ready libraries to do that easily. We need to keep cluster compatibility stuff so we'd either need multiple versions of libosinfo on engine or mirror and manage most of the provided useful properties in the extra properties ourselves. In previous comments there are more realistic suggestions, compacting the list, obsoleting the old ones...
*** Bug 1444458 has been marked as a duplicate of this bug. ***
Since Bug 1444458 has been merged please also keep in mind: When creating a new VM in the RHV Gui and selecting "Operating System", the OS chooser showns stuf like "Debian 7" and "Free BSD" as first choice. You need to scroll far down to get "RHEL 7" We should present RH Products first, and don't start the list with BSD.
There are no plans to move to osinfo, and this will not be fixed in a reasonable amount of time. If you'd still like this resolved, please re-open.
This can use the same hardware profile as RHEL7, which supports essentially every virtio device type, which we can safely assume are in 4.x
(In reply to Ryan Barry from comment #46) > This can use the same hardware profile as RHEL7, which supports essentially > every virtio device type, which we can safely assume are in 4.x current Other Linux is actually almost the same as RHEL 7 64bit, so everything should work there the same, as is Debian 7 or all those Ubuntus. Is there anything not working with Other Linux?
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops
Verified U/S and D/S: ovirt-engine-4.4.0-0.0.master.20190611123615.gitff372b3.el7 vdsm-4.40.0-310.gitbf1f64f.el7.x86_64 rhvm-4.3.4.3-0.1.el7.noarch vdsm-4.30.17-1.el7ev.x86_64 Verification scenario: 1. WebAdmin: Verify "Other Linux (Kernel 4.x)" is available in the next drop boxes: edit/new VM dialog, import dialog and import as OVA dialog. 2. Install from ISO the next operating system, while selecting "Other Linux" in edit VM dialog: - Fedora 25 - Debian 9 - FreeBSD 10.3 - openSUSE 15.1 - Ubuntu 18.04.2 Verify installation completed and VMs are running properly. install qemu-guest-agent (if not installed) from repo or by attaching RHV-toolsSetup.iso CD and validate qemu-ga functionality. 3. Export/import VMs as OVA, select "Other Linux" OS type in import dialog. Verify import completed and VMs are running. validate qemu-ga functionality. 4. Import from VMware VM which have kernel 4.x based OS, in the second import dialog, attach RHV-toolsSetup.iso and set "Other Linux" OS type. Verify import completed and imported VM is running properly. Validate qemu-ga functionality.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:1566
*** Bug 1738928 has been marked as a duplicate of this bug. ***