Il giorno dom 4 apr 2021 alle ore 16:13 Nicolas Kovacs <info@microlinux.fr> ha scritto:

Hi,

I'm a 53-year old Austrian living in Montpezat, a small village in South France. I'm an IT professional with a focus on Linux and free software, and I've been a Linux user since Slackware 7.1.

Welcome to oVirt community!

I'm doing web & mail hosting for myself and several small structures like our local school and a handful of local companies. Up until recently these hostings have happened on "bare metal" root servers using CentOS 7. One main server is hosting most of the stuff: WordPress sites, one OwnCloud instance, Dolibarr management software, GEPI learning platform, Postfix/Dovecot mail server, Roundcube webmail, etc.

This setup has become increasingly problematic to manage, since applications have more and more specific requirements, like different versions of PHP and corresponding modules.

So I decided to split everything up nicely into a series of virtual machines, each one with a nicely tailored setup.

I have a couple of sandbox servers, one public and one local, running Oracle Linux 7 (a RHEL clone like CentOS). I played around with it, and KVM-based virtualization already works quite nicely.

While looking for documentation, I stumbled over oVirt, which I didn't even know existed until last week. Before I dive head first into it, I'd be curious to know a few general things.

1. Would it be overkill for a small structure like mine?

If you have only a couple of bare metal and a few VMs you may consider more lightweight virtualization managers like cockpit project machine plugin ( https://cockpit-project.org/guide/latest/feature-virtualmachines ) or kimchi project (https://github.com/kimchi-project/kimchi ) or virt-manager ( https://virt-manager.org/ )

2. Will I be able to do HA on a series of modest KVM-capable root servers even if they are located in different datacenters across different countries?

I think it mostly depends on the network latency and speed. Having HA with servers in different countries may be problematic.

3. One problem I couldn't resolve using a bone-headed keep-it-simple KVM setup is backup. For my bare-metal servers I've been using incremental backups using Rsnapshot for years. Here's a blog article I wrote on the subject:

https://blog.microlinux.fr/rsnapshot-centos-7/

Unfortunately I can't use this approach with huge QCOW images, at least not without jumping through burning loops.

Is there an easy way to perform remote incremental backups with oVirt?

There are a few backup vendors that provide solutions for backing up oVirt VMs, you can just query google for them.

BTW, I took a peek at Proxmox and Ceph, but I admit I'm a die-hard RHEL-clone user.

Cheers from the sunny South of France,

Niki

-- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12 _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/I734ZR3ITWA6RS...

-- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. <https://mojo.redhat.com/docs/DOC-1199578>*

That very much describes my own situation two years ago..., just a slight time and geographic offset as my home is near Frankfurt and my work is in Lyon. I had been doing 70:1 consolidation via virtualization based on OpenVZ (containers, but with a IaaS abstraction), since 2006 because it was zero hardware and software budget whereas VMware would have both requried VT-x capable hardware and pricey licenses. OpenVZ turned out extremely easy to use, super reliable and the sysadmin only had to learn two or three new commands, not a new abstraction layer. We were running payment front office systems, where five minutes of downtime mean a very angry boss, one hour of down time costs a yearly bonus and beyond that you have to gather your things and go. That also meant planned 100% availability of eventually consistent data, so nothing you could do on a file level: Oracle with streams replication and programmed healing or nothing, that meant at the time, can't beat the CAP theorem. (No this isn't a recommendation to go with OpenVZ: That project is about as lively as Docker these days). For a new context with far lighter avaiIability demands but the need to support GPUs for machine learning (CUDA breaks OpenVZ containers) I thought that oVirt would add managed heterogeneous VMs and hyperconverged storage to the mix, again at zero entrance fee with a supported option if that became necessary. Two years later, I'd say that "I married the wrong woman". It works, but the claim "oVirt is an open-source distributed virtualization solution, designed to manage your entire enterprise infrastructure" is terribly misleading. I had planned to get it reasonably stable and ready within weeks of my typical stress and failure testing on 1/3 time budget, but it took almost 2 years and more like 50% time allocation to learn all the very many things that can go wrong, how to diagnose them and how to fix them. Just yesterday I had one cluster (my 1st functional test 3 node HCI running on Atoms, that mostly just sits idle and gets updates, which require reboots), had evidently decided to lose one gluster network connection and accumulated 5000+ entries in the heal queue during a week of vacation. It was four hours of careful digging, hundreds of restarted daemons, various reboots and a transient situation where the three storage nodes could not see or access the storage they were providing, while the management engine ran on a compute node and continued to write to a disk that evidently did not exist... As a newbie I would have either jumped off a cliff (active users) or tossed the project. However, the magnificent basic design of oVirt had me recover everything without a loss... except hair, nerves, general health etc. And I had to learn the hard way, that just exporting a VM as an OVA and expecting it to be importable on any other platform advertising OVA support, or even back into oVirt, is not functionality ever included in any regular QA testing... ...which might explain why it doesn't work. Or perhaps just no longer, after an update. In short: do not expect anything to work, that you have not fully tested after every minor update--several times: everything is extremely raw and ready to break at any moment and I can't remember the last time I did a plain vanilla install on freshly scrubbed hardware, where I didn't have to help it along manually and with digging through dozens of big log files. What really troubles me: since the basic ingredients for the commercial product are the same, I don't see how that might save your bacon. Perhaps 100% validated hardware might do it (for a while), but where oVirt is *designed* for a maximum of flexibility, it won't reward your taking advantage of that. I am sticking with it until CentOS7 is end of life, too (just like CentOS8 is already), because otherwise I'd have nothing to show for two years of work. But if you want to join in, you need to have serious resources to commit. It's most likely still smaller than OpenStack, though. And if you have NetApp filers or SAN, you should not risk HCI. That is super elegant as a concept, just like Gluster is a beautiful concept, but very soon you'll realize that they were never designed for each other and remain full of contradictions. oVirt may be designed to fit that enterprise role, but in the HCI variant, it stil has nowhere near the cohesion and maturity you'd need for that role. CentOS, LVM, VDO, KVM, the management engine, Gluster, Ansible are all distinct products from what used to be different companies. And it shows. Of course, that's just my personal experience and opinion.