D4Science Infrastructure

Still no progress. I've something else to try tomorrow, after than I'll install the engine host outside a VM.

Update:

I was able to complete the installation of the oVirt engine in virtualized/HA mode, and the installation of another host.
But when I tried to reinstall that host to add the HA services needed to migrate the hosted engine, that host went to an inconsistent state.
I guess that all the three hosts involved (dlib17x, dlib18x, dlib19x) had too many inconsistent configuration from my past attempts.

So I decided to remove all the virtualisation packages, configurations, and network setup from the three hosts to start from scratch.
Some problems remain:

• dlib17x has currently no connectivity on the main interface, don't know why.
• dlib14x did not come on line again after a reboot (I don't have the console here)

About gluster: I manually created a new volume after the successful installation. As it's possible to use logical volumes as bricks (this is the way used by the automatic configurator, btw) I created a data volume where each brick is composed by three disks. This simplifies the configuration. disks or partitions can be added to a volume after the volume has been created, anyway.

Last, security: gluster can use ACLs to limit the authorized clients, but as firewalld does not permit to limit the sources, we could face problems with all services hosted on the hypervisors. Maybe we could ask the IIT people to create firewall rules for us, that cover both the hypervisors and SAN public IP addresses? We could block everything incoming but ssh (and perhaps that too).

I've reported the required steps and links to the documentation in the internal wiki: https://support.d4science.org/projects/aginfraplut/wiki/OVirt_Hypervisors_configuration_and_setup

about the firewall rules: it's possible to use the direct rules functionality of firewalld, to add plain iptables rules. Our firewalld role already supports the scenario.

The hyperconverged host installation went well, but I'm now stuck because there should be a configuration section in the administration dashboard that is not present in our. As it's the one that must be used to configure the storage network it's quite important. So I suspended the operations and asked for help in the ovirt users mailing list.

All the hosts are up.

The problem with the interfaces on dlib 14x/17x is bad. There's no way to make them working reliably it seems. I tried various options, following the directions that I've found here: https://helpful.knobs-dials.com/index.php/Forcedeth_notes but without any effect. Some files with the options are present on dlib17x and dilb15x under /etc/modprobe.d/forcedeth.conf.

As the interfaces worked well when they were not used as a bridge, we could try to swap the interfaces: use the intel ones on the public network and the NVIDIA (forcedeth) on the storage one. We could try on one of the servers. If it does not work, the safest solution is to only use the Intel cards without any bonding.

We abandoned the bond configuration on the dlib1[5:7]x servers and after that the setup went well.

And about the firewall configuration, we've found a way that seems compatible with firewalld. The executed commands are:

firewall-cmd --zone=public --add-source=146.48.80.0/21
firewall-cmd --zone=public --add-source=146.48.122.0/23
firewall-cmd --zone=public --add-source=10.0.0.0/8
firewall-cmd --zone=public --add-source=192.168.0.0/16
firewall-cmd --zone=public --add-source=146.48.122.0/23 --permanent
firewall-cmd --zone=public --add-source=146.48.80.0/21 --permanent
firewall-cmd --zone=public --add-source=10.0.0.0/8 --permanent
firewall-cmd --zone=public --add-source=192.168.0.0/16 --permanent

firewall-cmd  --set-default-zone=drop

Those commands move the two interfaces on the drop zone so that the traffic is blocked by default, while on the public zone the access is granted to the selected networks only.