Description of problem: 'Managed by: oVirt Engine $host' is visible even the host is in pending state, this seems odd. What about this: Managed by: oVirt Engine $host (pending) ...or: Managed by: oVirt Engine $host Status: pending Version-Release number of selected component (if applicable): Red Hat Enterprise Virtualization Hypervisor release 6.5 (20140513.0.el6ev) How reproducible: 100% Steps to Reproduce: 1. boot from pxe with management_server=$your_rhevm 2. check Status in rhevh tui 3. Actual results: the host is in RHEVM in pending state but RHEVH Status tab shows it is managed by RHEVM. Well... not yet. Expected results: Either do not lie in this time or distinguish that it is pending for approval be to Managed by... Additional info: I doubt about sense of current 'Status: Virtualization hardware was detected and is enabled' Who cares about it? I think installation should fail completely if host HW is not good enough for being RHEV host :)
Hi Fabian, Any suggestion to handle this one? I would suggest that this report might require BZ#1093884. What do you say? > 'Status: Virtualization hardware was detected and is enabled' > > Who cares about it? I think installation should fail completely if host HW > is not good enough for being RHEV host :) Users can enable virtualization in the host if it's disable in the BIOS after installation.
(In reply to Douglas Schilling Landgraf from comment #1) > Hi Fabian, > > Any suggestion to handle this one? I would suggest that this report might > require BZ#1093884. What do you say? No, no suggestions. But IMO the referenced bug above is the right direction. IIUIC the information is currently not available (if registeration is pending), thus: Before we can expose/use this information in the UI it needs to be made available, which needs to be handled by vdsm-reg or it's successor - or whatever component. And further more - the vdsm_reg rewrite is currently targeted upstream for 3.5.
(In reply to Fabian Deutsch from comment #2) > (In reply to Douglas Schilling Landgraf from comment #1) > > Hi Fabian, > > > > Any suggestion to handle this one? I would suggest that this report might > > require BZ#1093884. What do you say? > > No, no suggestions. But IMO the referenced bug above is the right direction. > IIUIC the information is currently not available (if registeration is > pending), thus: Before we can expose/use this information in the UI it needs > to be made available, which needs to be handled by vdsm-reg or it's > successor - or whatever component. Thanks Fabian, I do believe if ovirt-engine expose this data and any component can consult without authentication we could do it directly in ovirt-node-plugin-vdsm.