Bug 1279631

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

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 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.

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'."

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.

I will setup new oVirt/RHEV instance and reproduce, will take some time.

https://github.com/abenari/rbovirt/pull/99

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.

https://access.redhat.com/errata/RHSA-2016:0174

Thanks for verification!