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 _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/G5HWL5XN3EEI3UHQACSUNTXVNFZ2V56X/
