Bug 1279631 - Network Based Provisioning of New Host in RHEV fails with "No bootable device."
Network Based Provisioning of New Host in RHEV fails with "No bootable device."
Status: CLOSED ERRATA
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Compute Resources (Show other bugs)
6.1.3
Unspecified Unspecified
unspecified Severity urgent (vote)
: 6.1.7
: --
Assigned To: Lukas Zapletal
Kedar Bidarkar
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-09 16:58 EST by Sebastian Hetze
Modified: 2017-02-23 14:40 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-15 10:52:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sebastian Hetze 2015-11-09 16:58:19 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):
Satellite 6.1.3

How reproducible:
always

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

Actual results:
Intallation fails with "No bootable device."

Expected results:
Installation proceeds with kickstart.

Additional info:
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)
Comment 1 Ohad Levy 2015-11-16 09:48:05 EST
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?

thanks
Comment 2 Maxim Burgerhout 2015-11-30 09:55:02 EST
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.
Comment 4 Ohad Levy 2015-12-01 04:19:45 EST
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.
Comment 5 Michal Skrivanek 2015-12-01 11:48:19 EST
(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?
Comment 6 Ohad Levy 2015-12-02 07:06:21 EST
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.
Comment 7 Ohad Levy 2015-12-02 07:08:24 EST
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?
Comment 8 Michal Skrivanek 2015-12-02 12:33:55 EST
(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.
Comment 9 Ohad Levy 2015-12-03 02:28:36 EST
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.
Comment 11 Maxim Burgerhout 2015-12-03 03:12:06 EST
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 :)
Comment 12 Sebastian Hetze 2015-12-04 02:19:14 EST
To my deepest regret it still does not work for me.

Using Satellite 6.1.4 and RHEV 3.5.6.2 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.
Comment 13 Ohad Levy 2015-12-08 04:31:13 EST
I wonder, can you set the boot order on the template? (then the inherited vm also uses the same order)?
Comment 14 Lukas Zapletal 2015-12-08 10:12:25 EST
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'."

https://bugzilla.redhat.com/show_bug.cgi?id=984290

https://github.com/abenari/rbovirt/issues/39
https://github.com/abenari/rbovirt/pull/40

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.
Comment 15 Lukas Zapletal 2015-12-10 11:46:35 EST
I will setup new oVirt/RHEV instance and reproduce, will take some time.
Comment 16 Lukas Zapletal 2016-01-07 07:19:27 EST
https://github.com/abenari/rbovirt/pull/99
Comment 19 Kedar Bidarkar 2016-02-04 05:40:10 EST
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.
Comment 21 errata-xmlrpc 2016-02-15 10:52:03 EST
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/RHSA-2016:0174
Comment 22 Lukas Zapletal 2016-02-23 08:12:54 EST
Thanks for verification!

Note You need to log in before you can comment on or make changes to this bug.