That's exactly the point: Running oVirt on top of a vanilla KVM seems to be the only
case supported, because the Redhat engineers use that themselves for development, testing
and demoing.
Running virtual machines nested inside an oVirt VM via KVM also works per se, as
HostedEngineLocal during the setup is working, can be talked to etc. from the host that is
running the setup, because it uses a local bridge. You can even reach everyone from within
that nested VM on the outside, but the VM itsself is only accessible from the host at the
point (normal in all cases).
But in the next stage of the installation that locally prepared VM is modified to run on
the cluster storage, gluster in the HCI case and use the overlay network and that's
where it loses network connectivity, I guess because overlay networks lack nesting (I
guess there is still a non-overlay way to run oVirt and then perhaps it even works...)
And while I admire that network overlay stuff, it's also black magic to me, and
evidently not trivial if not downright impossible to resolve, which is most likey why the
Redhat engineers don't seem to pursue that path. At least that's what I read from
this comment, which really should be somewhere right next to where "nested
virtualization" is ever mentioned, to ensure expectations are properly managed.
https://lists.ovirt.org/pipermail/users/2017-March/080219.html