Hide Forgot
Description of problem: Direct kernel/initrd booting for VMs is supported by libvirt/qemu, and was added to oVirt in the past. However, this feature is not utilized by end users, and the backend support depends on directly moving these files through a mechanism which is not data domains. Rather than rewriting to use data domains (similar to the existing ISO bugs), it's better to remove it from the following: UI REST API Any ansible code which may invoke it
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.
This makes accessing the the boot options (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options) impossible. What is the rationale of removing this? "this feature is not utilized by end users"?! We actually did intend to use the kernel_params of the Ansible ovirt_vm module to initiate a kickstart installation process of a guest VM. Now that support is removed, we're left without a visible alternative. Are there remaining alternatives to controlling boot options via Ansible (e.g. ovirt_vm) or the REST API now?
Well, the alternatives are: * PXE installation * embed a kickstart onto the ISO * Provision with Foreman * Make/seal a template out of a VM * Configuration of a pre-built image with cloud-init Are there any required boot options outside of inst.ks?
What would be the reproduction steps?
Open the runonce dialog and VM boot settings and see that the option is not there (it is present in 4.3)
(In reply to Ryan Barry from comment #5) > Open the runonce dialog and VM boot settings and see that the option is not > there (it is present in 4.3) You can't get in to run once, while engine VM is still running. Engine's VM should be running all the time, otherwise you won't be able to get to the GUI. Can you please clarify? For the regular VMs this functionality was disabled.
In edit engine's VM this functionality is disabled. NFS deployment on these components: rhvm-appliance.x86_64 2:4.4-20200123.0.el8ev rhv-4.4.0 sanlock-3.8.0-2.el8.x86_64 qemu-kvm-4.2.0-12.module+el8.2.0+5858+afd073bc.x86_64 vdsm-4.40.5-1.el8ev.x86_64 libvirt-client-6.0.0-7.module+el8.2.0+5869+c23fe68b.x86_64 ovirt-hosted-engine-setup-2.4.2-2.el8ev.noarch ovirt-hosted-engine-ha-2.4.2-1.el8ev.noarch Linux 4.18.0-183.el8.x86_64 #1 SMP Sun Feb 23 20:50:47 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux release 8.2 Beta (Ootpa) Engine is: Red Hat Enterprise Linux Server release 7.8 Beta (Maipo) Linux 3.10.0-1123.el7.x86_64 #1 SMP Tue Jan 14 03:44:38 EST 2020 x86_64 x86_64 x86_64 GNU/Linux Moving to verified.
Right, this would not be for the HE VM. Just RunOnce for normal VMs. However, it's been raised that multiple customers are actually dependent on this functionality. It was just one of those rare features which worked flawlessly for years, so we thought they were no consumers. Liran, can you revert the patches?
Moving to POST, revert patches are posted.
(In reply to Ryan Barry from comment #8) > Right, this would not be for the HE VM. Just RunOnce for normal VMs. > > However, it's been raised that multiple customers are actually dependent on > this functionality. It was just one of those rare features which worked > flawlessly for years, so we thought they were no consumers. > > Liran, can you revert the patches? I don't see this functionality in 4.4 also for regular guest VMs. Moving to verified forth to Verified forth to https://bugzilla.redhat.com/show_bug.cgi?id=1732437#c7 and also to that I didn't found such functionality for guest VMs in new version.
All the revert patches are now merged.
I don't see functionality reverted on rhvm-4.4.0-0.31.master.el8ev.noarch.
Deployment was made Today using rhvm-appliance.x86_64 2:4.4-20200403.0.el8ev. The fix on revert is not there.
Tested on: rhvm-appliance.x86_64 2:4.4-20200403.0.el8ev ovirt-hosted-engine-setup-2.4.4-1.el8ev.noarch ovirt-hosted-engine-ha-2.4.2-1.el8ev.noarch Build 29.
(In reply to Nikolai Sednev from comment #18) > Deployment was made Today using rhvm-appliance.x86_64 > 2:4.4-20200403.0.el8ev. The fix on revert is not there. What is missing?
(In reply to Liran Rotenberg from comment #21) > (In reply to Nikolai Sednev from comment #18) > > Deployment was made Today using rhvm-appliance.x86_64 > > 2:4.4-20200403.0.el8ev. The fix on revert is not there. > > What is missing? The functionality is not there.
It required to set VM to be Linux type, then functionality becomes visible. Tested on: rhvm-appliance.x86_64 2:4.4-20200403.0.el8ev ovirt-hosted-engine-setup-2.4.4-1.el8ev.noarch ovirt-hosted-engine-ha-2.4.2-1.el8ev.noarch
Ryan, I see now that the changes described in the doc text have been reverted, so if doc_text is no longer required, please update accordingly to remove doc text.
(In reply to Timoses from comment #2) > This makes accessing the the boot options > (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ > html/installation_guide/chap-anaconda-boot-options) impossible. > > What is the rationale of removing this? "this feature is not utilized by end > users"?! > > We actually did intend to use the kernel_params of the Ansible ovirt_vm > module to initiate a kickstart installation process of a guest VM. Now that > support is removed, we're left without a visible alternative. > > Are there remaining alternatives to controlling boot options via Ansible > (e.g. ovirt_vm) or the REST API now? I'd like to add that I was also shocked to see that see this feature was being removed. I use the `kernel_path`, `initrd_path`, and `kernel_params` in the Ansible `ovirt_vm` module in my ansible playbook (https://github.com/lukepafford/ansible2/blob/1bddf7e1475cfe3c1c2c77bb947dfbf21a2105ef/playbooks/create_vm/create_vm.yml#L60). It allows me to completely automate the VM creation process, and it only relies on a single playbook. Any alternative to this method seems inferior so I hope it isn't removed or else it looks like I'm staying on Ovirt 4.3.
This was actually reverted once we realized it was still used, so the functionality will remain
(In reply to Ryan Barry from comment #26) > This was actually reverted once we realized it was still used, so the > functionality will remain Please see comment 26: If the changes described in the doc text have been reverted, then doc_text is no longer required, please update accordingly to remove doc text.
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.