[ovirt-users] No bootable device on Centos 7 - ovirt 3.5 hosted-engine install.

[Lewis Shobbrook]

Hi Guys, 

I struck upon the same problem that I've seen posted to the list some time ago, where attempts to install the hosted engine fail. 
The problem of "No bootable device" on first reboot after the initial installation of the hosted-engine via an iso based cdrom install, is reproducible across different installation media. 
To describe in a little more detail for clarity, after the initial reboot and reconnection to the hosted-engine setup VM, one must select "Boot from local drive" or the likes from install media to continue with the hosted-engine setup. 
At this point regardless of install media, (e.g. CentOS-6.6-x86_64-minimal.iso or the Fed 20 equivalent, or even the Debian Jessie net-install iso), the "No bootable device" error persists.
I did see some suggestion that the problem may have been related to iptables, but my assessment this is not the case.
The work around that I found was to edit the grub entry for "Boot from local drive" in the iso menu from ".localboot 0xffff" and changing it to ".localboot 0x80"

Essentially what I was able to gather about the problem was that it was new to Centos7, and was not encountered in earlier versions nor alternate host OS such as Fedora 20. 
Also the apparent bug is related only to the ovirt-hosted-engine-setup created instance.
Post installation, an ovirt 3.5 created VM hosted on Centos 7, using identical media and booting back to the iso by default, does not exhibit the "No bootable device" error.
I have also been able to reproduce the problem on different hardware with fresh Centos 7 installs separated by 7 weeks, so it seems persistent since early October at the RC stage til now.

Other problems that I encountered with the hosted engine install relate to the iptables installation on the hosts/nodes following successful engine-setup, despite selecting the "No" option for iptables configuration within the ovirt-hosted-engine-setup dialogue.
My memory from the 3.4 release is that when performing the New host task from the GUI and unchecking the iptables option, that it would similarly reconfigure iptables on the target host as well.
It appears that the selection is not honored and from my experience breaks component hosts of glustered HA platforms.

I will get to submitting on bugzilla soon, but thought it may help to share this here too.

Lew