
I am trying to teach myself new and better means to deploy and control oVirt and HCI deployment. Does anyone have notes, experience and or examples.. website etc.. where someone managed deployment and admin of HCI deployment (CentOS + Cockpit + gluster + oVirt) and instead of using shell and manaual / gui deployment, did this "Infrastructure as code" Ex Step 1: 1) Foundation with kickstart. three nodes with "minimal install" all with ssh keyless password login for user "ansible" 2) Keys exchanged between nodes for keyless login for root and ansible user 3) Using ansible publish HCI deployment playbook. -> Define drive for each host to use -> Define name and host / ip of engine -> install HCI engine with gluster -> Add SSH keys for ansible and access so future oVirt interaction can be done via ansible I am just starting to research this.. but hoping others have blazed this path and I can leverage their process. Concerns: 1) How to get HCI to deploy only engine layer on (in my case... 512GB SSD .. with VDO and avoid destroying VMS not related to engine).. aka if I have to repair engine again will it keep nuking the volumes "data" and "vmstore" volumes which I think the HCI deployment wants to do if it has to redeploy fresh. 2) If above is always to be an issue .. can I make default VM deployment be a dedicated gluster volume (my case is 1TB SSD with VDO in each server) such that rebuild of engine layer can just slurp back in the VMs from that volume.

2) If above is always to be an issue .. can I make default VM deployment be a dedicated gluster volume (my case is 1TB SSD with VDO in each server) such that rebuild of engine layer can just slurp back in the VMs from that volume. It is highly recommended (well actually all devs will say required)
that you have a separate datastore for the HostedEngine and no VMs should be hosted there. That's why the cockpit deployment is creating a dedicated volume. Best Regards, Strahil Nikolov

HCI creates three volumes engine data vmstore engine is dedicated for just hosted engine and its database... this one I think will be a control plane that I hope with tasks like snapshots.. upgrades and patches could be deployed with some aspect of recovery.. but if that fails.. redeployment would be isolated. data and vmstore .. I think this is for hosting the Database for oVirt iso storage, but if the engine is down.. and its database.. no way to stich the VMs back together. Some VMs I just need streamline way to ingest back into new deployed engine. Maybe someone has script to parse those volumes and offer "would you like to import these VMs"
participants (2)
-
penguin pages
-
Strahil Nikolov