IIRC, we intentionally introduced reboot to vdsm installation so that we can be sure(r) that future reboots will work too. We can do a network restart instead (and be less sure). I don't know if we WANT to do that.

Understood.  The problem is, if vdsm requires a reboot then the installation process for RHEVH will require 2 reboots to be complete rather than 1.

Right now process is:

boot RHEVH from install media, configure, install to disk, reboot
vdsm starts on the next boot and you're ready to go

The new process for installing RHEVH (input from both UX and Desktop teams) is to separate configuration from 'installation'.  So this means vdsm will not be configured during the first boot from the install media.  That means the process would be:

boot RHEVH from install media, install to disk, reboot
configure networking and vdsm, reboot
vdsm starts and you're ready to go

It's up to the RHEVM team (eng and PM) to determine how best to configure vdsm in light of the RHEVH usability enhancements.  Core RHEVH will not require 2 reboots to be functional.  But if vdsm requires the 2nd reboot, that will just have to be spelled out in the documentation.

(In reply to comment #0)
> Description of problem:
> Currently in RHEVH, vdsm requires a reboot between the registration phase and
> when vdsm starts for the first time.
> 

Sorry Perry & Dan, but this is not the case.
There's no need to reboot a RHEV-H machine due to VDSM installation.
In my past work with Alan, we integrated the registration phases to
fit the oVirt reboot mechanism (ie- first boot is config & install, so
oVirt local installation needs reboot and 2nd boot has everything it needs).

According to these phases, What registration actually has is:

[First boot]

- PXE boot (uses vdsm-config script)
Extract PXE parameters and create basic VDSM configuration file.

- CD/USB (manual) install (uses config-rhev-manager script)
Ask PXE param's from the user and create basic VDSM configuration file.

[Second boot and later]

- Executed by vdsm-reg service (vdsm-reg-setup script)
* Rename brethX bridge if needed.
* Get RHEV-M SSH public key.
* Post local information to RHEV-M.

- (Optional) Certificate generation (vdsm-gen-cert.py script)
* Clean existing key pair & certificates
* Generate new key pair & certificate request.

- (Optional) Registration completion (vdsm-complete.py script)
* Install new certificate
* Set core dump param's
* Cleanup
* Update vdsm configuration (if needed)
* <<<Restart>>> vdsmd service.

Note that the last 2 steps are initiated from RHEV-M by an administrator and won't occur if the RHEV-H machine is already registered.

So as you can see, the only thing we require is service restart so
vdsm can update it's security context & configuration.

One more thing that has to do with reboot, is RHEV-H upgrade, using an alternate ISO. In this case as well, the need for reboot comes from RHEV-H.

Hope this response will clarify things. The BZ itself is not a bug (IE-
your RFE has been answered :)

Thanks for the detailed explanation Doron.  Agreed that this RFE has been satisfied already, so will close as CURRENTRELEASE.