Red Hat Bugzilla – Bug 1279631
Network Based Provisioning of New Host in RHEV fails with "No bootable device."
Last modified: 2017-02-23 14:40:42 EST
Description of problem:
When provisioning a New Host with RHEV Compute Resource using Network Based method, installation fails with "No bootable device."
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create Compute Resource with RHEV-3.5 backend, default settings
2. Create New Host using "Network Based" Provisioning Method
3. Open console window for new host
Intallation fails with "No bootable device."
Installation proceeds with kickstart.
As workaround you can either stop the VM manually and use the "Run Once" button in RHEV-M to move PXE boot to top, or you can create a new empty template in RHEV with PXE as first boot option and assign this template to the compute profiles (Thanx Maxim Burgerhout for finding this workaround)
pxe booting is by default set when creating the vm in rhev (see https://github.com/theforeman/foreman/blob/develop/app/models/compute_resources/foreman/model/ovirt.rb#L140)
any chance you can double check why the vm is created from boot from disk in the first place? e.g. do you use a template that force boot order or anything else?
is this consistent with all rhev version? something else that you could think of why it does not work?
Ohad, answering comment 1 here:
A VM on RHEV is created by cloning the 'Blank' template. This is the default and used for creation of *every* VM, unless another template is explicitly specified.
If you specify another (self-made) template that forces PXE in Satellite, deployment works. But if you do not create a self-made template, your VMs, based on the default 'Blank' template, will boot from disk and never from network on their first boot.
I don't think
:first_boot_dev => 'network'
currently has any effect on the way to boot order is layed out, to be honest.
I have tried with 3.5.x on several occasions.
I'll leave needinfo? in for shetze, in case he wants to add something else.
adding mskrivan, do you happen to know if there was an API change in 3.5 regarding vm boot order? this used to work before.
(In reply to Ohad Levy from comment #4)
> adding mskrivan, do you happen to know if there was an API change in 3.5
> regarding vm boot order? this used to work before.
There were changes of how attributes are resolved from the blank template...might be related. Though explicit specification should always override it. What does first_boot_dev map to in our REST API? Can anyone share the actual request so we can try it out?
Maxim, further investigation revealed https://github.com/abenari/rbovirt/commit/455c65736ce5dfbae84466fcde3c3e787c1cd795 which I believe exactly the issue you are describing.
I'm adding lzap if he can provide the background for the reasoning of why disabling this feature.
Michal - it looks we involved you too quickly.. sorry for the trouble and thanks.
Am I reading it correctly? that via the API a os section can't be sent when using a template? and that the only way to define the boot order is within an os section?
(In reply to Ohad Levy from comment #7)
> Am I reading it correctly? that via the API a os section can't be sent when
> using a template? and that the only way to define the boot order is within
> an os section?
the logic does not seem right to me. The os element must not conflict with the selected template's graphic device. I.e. If the template has single_qxl_device option which is only valid for Linux OS types, you can't override the OS type to Windows which doesn't support it. In general you should not ever need to specify it explicitly. If you allow modification/override then you should do that via our API since it may change other properties specific for Win/Lin
Regardless all that, Boot order is OS agnostic indeed.
So what is the right way to handle this? via a follow up api to change the boot order? or rather remove the graphical device from the os section when sending the api?
not sure if its related, but we do care about spice/vnc configuration as we define the display and later on display it within satellite (e.g. novnc,spicejs etc).
I would like to bump this to z-stream as this breaks provisioning on all rhev instances based on templates.
Can no longer (completely) reproduce with Sat 6.1.4 and RHEV 3.5.6.
Where new VMs used to hang at 'No bootable device', I now see an attempt to boot from disk, then from CD-Rom and finally it does a PXE boot.
In the VM configuration, only Hard Disk is enabled as first boot device. Second boot device is unconfigured in the interface. It still does *not* set network as first boot option, but it does end up doing a PXE boot.
As far as I can tell, this is new behavior. I used to see the same thing as Sebastian.
@Sebastian, can you verify that with the new versions of RHEV and Sat6, your VMs try different boot options, too? I would like to exclude the possibility that I 'fixed' something that I forgot about :)
To my deepest regret it still does not work for me.
Using Satellite 6.1.4 and RHEV 18.104.22.168 I still get "no bootable device" error when trying to deploy a new host using network based provisioning with the standard Blank template from RHEV.
The workaround using a selfmade empty template still works.
I wonder, can you set the boot order on the template? (then the inherited vm also uses the same order)?
The patch in rbovirt was created because of:
"Previously, 'Unassigned' was the default option for the Operating System field in the New or Edit Virtual Machine window. This option has now been deprecated, and replaced with 'Other OS'."
It used to work with 3.5 version, I am not sure what changed. My beaker tests of oVIRT - rbovirt are broken for some time now.
I will setup new oVirt/RHEV instance and reproduce, will take some time.
Thanks for clarifying this @shetze, I had tested it earlier but without the "compute profile".
VERIFIED with Sat6.1.7 compose.
So I tested by provisioning with "3-Large" compute profile and 'Network Based Provisioning' and it works fine.
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.
Thanks for verification!