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. 
Users mailing list --
To unsubscribe send an email to
Privacy Statement:
oVirt Code of Conduct:
List Archives:

Reply via email to