Bug 1296148

Summary: Adding bad host as the first in the cluster results in an unusable cluster even when it is fixed
Product: [oVirt] ovirt-engine Reporter: Barak Korren <bkorren>
Component: BLL.VirtAssignee: Michal Skrivanek <michal.skrivanek>
Status: CLOSED NOTABUG QA Contact: Ilanit Stein <istein>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.6.1.3CC: bugs, oourfali
Target Milestone: ---Flags: rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-08 17:13:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Barak Korren 2016-01-06 13:14:58 UTC 
Description of problem:
When the first host added to the cluster cannot do virtualization for some reason (disabled in BIOS, or the host is a VM with a cpu type that does not support nesting), the cluster's cpu type and and architecture settings do not get properly initialized. If the host is then fixed by moving it to maintenance mode, repairing the issue and activating, the cluster will be activated, but the cpu type and architecture settings will remain in badly initialized state.
This will result in a cluster in which VMs could not be created.

Version-Release number of selected component (if applicable):
3.6.1.3-1.el7.centos

How reproducible:
Its easy to reproduce by using nested virtualization and libvirt.
You will need: engine installed, some storage, and a host to run a nested host VM on (we will call it the "physical host"). That physical host should not be managed by the engine. 
In my tests the engine, storage and (non-physical) host were all VMs on my Laptop.

Steps to Reproduce:
1. Create a VM to use as a host, set it up with a CPU that does not support nested virtualization (the libvirt default in EL7 does not for example)
2. Install OS in the VM (for example by creating a disk for it with virt-builder) and setup the oVirt repos for it.
3. Create a new cluster, we`ll call it 'cluster1'. if this is a completely new engine system, the 'Default' cluster coudl be used as well.
3. Attempt to add the VM as a host to cluster1, this will fail complaining about the CPU type.
4. Move the host into maintenance mode, shut down the VM, and change the CPU type to something that can do nested virtualization.
5. Bring the host VM back up, go to engine and activate it. Activation will succeed, cluster1 will be activated, and if this is the first host in the DC, the DC will be initialized and the host will become the SPM.

Actual results:
cluster1 cpu architecture and type in the cluster will remain blank.
Trying to create a VM will not allow selecting cluster1.

Expected results:
The cluster should now be fully functional

Additional info:
Comment 1 Michal Skrivanek 2016-01-08 17:13:04 UTC 
This is by design. Firt joined host sets the fundamental cluster properties

there is an explicit recent on right click menu. Use that
Comment 2 Barak Korren 2016-01-10 07:35:49 UTC 
Why should something that is don implicitly when you add a host should be done explicitly when you 'fix' it?
This is a very bad UX, there was no indicator that the cluster is malfunctioning other then the 'new vm' window being blank.