On Fri, May 29, 2020 at 11:39 AM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:

On Fri, May 29, 2020 at 9:34 AM Simone Tiraboschi <stirabos@redhat.com> wrote:

On Thu, May 28, 2020 at 11:56 PM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Thu, May 28, 2020 at 3:09 PM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:

[snip]

for the cluster type in the mean time I was able to change it to "Intel Cascadelake Server Family" from web admin gui and now I have to try these steps and see if engine starts automatically without manual operations

1) set global maintenance
2) shutdown engine
3) exit maintenance
4) see if the engine vm starts without the cpu flag....

I confirm that point 4) was successful and engine vm was able to autostart, after changing cluster type.

As expected,
in my opinion now the point is just about understanding why the engine detected your host with the wrong CPU features set.

To be fully honest, as you can see in https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/README.md#L46 , we already have a variable (he_cluster_cpu_type) to force a cluster CPU type from the ansible role but I don't think is exposed in the interactive installer.

Can I artificially set it into a playbook, just to verify correct completion of setup workflow or do you think that it will be any way overwritten at run time by what detected?

The interactive installer is not passing it and the default behaviour is to omit the parameter if the variable is unset to let the engine wisely detect and choose.

https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/tasks/bootstrap_local_vm/05_add_host.yml#L62

So yes, you can simply inject a custom value

It is not clear in my opinion what does it mean the sentence: "cluster CPU type to be used in hosted-engine cluster (the same as HE host or lower)"
With "as HE host" does it mean what gotten from vdsm capabilities or what?

Read this as "as first HE host". This parameter can be useful if you plan to add older hosts in the future and you prefer to start from the beginning with a CPU type for the cluster that's less required than what can be detected from the first one.

I tend to think that in the past the set of CPU features was monotonically increasing between a CPU family and a newer one. This is less easy now with all the different security patches.

That one is just a leftover from the install process.
It's normally automatically cleaned up as one of the latest actions in the ansible role used for the deployment.
I suspect that, due to the wrongly detected CPU type, in your case something failed really close to the end of the deployment and so the leftover: you can safely manually delete it.

Yes, the deploy failed because it was not anle to detected final engine as up....

As asked by Lucia, the Origin of the VM was "External"
The VM had no disks and no network interfaces. I was able to remove it without problems at the moment.
Thanks,
Gianluca