It has been 7 or 8 years since I touched it, but yes. I extended some intern-built VMware automation to ovirt so we could validate KVM images and reduce VMware costs for internal dev and because that was the platform the manager decided on. We initially only dedicated 6U or 8U to it.

In general, I’d say it worked just fine and the python sdk was approachable. It wouldn’t be my first choice knowing it’s Oracle Virtualization now, but that’s a moral stance instead of technical.

As for maintaining it long term, I can’t really say. I left that team to go play in the clouds with terraform and kubernetes. But I also haven’t heard anything negative from that team since (and I’m still friends with one of the system engineers who is responsible for it). And there was a much needed fundamental rewrite of the bits I original extended that continued with ovirt that went smoothly.

It sounds like you want to create a vm template image.

Some options:

Both virsh and virt-manager have tools for managing libvirt xml files that you can turn into a template to use for launching additional images.

Proxmox and ovirt both have template concepts and APIs you can interact with for automation.

If you’re looking to create a golden image or just automate configuration, virt-clone, ansible, puppet, packer, and even pxe boot are good options depending on the methods you prefer.

There are so many well-established ways to approach this problem domain. Just don’t get decision paralysis. There isn’t a best either.

Bold of you to assume people/companies test backups more than once.

Case in point: I once got instructed to “enable EBS snapshots” for customer deployments to meet a new backup requirement. Disaster recovery was a completely different feature we only kind of got to a couple years later and afaik, remains manual to this day.

As another commenter pointed out, the current issue is due to the docker-desktop package being maintained outside the normal channels (AUR) and not getting updated when one of its dependencies moves forward (qemu). CachyOS seems to be letting you install from AUR as part of your normal pacman process and it’s going to lead non-experts into situations like this. I separate my installs from AUR and system packages for this reason (among others).

Your choice is:

• just wait for the person who maintains the docker-desktop package to update it
• remove the docker-desktop package and update normally
• potentially break things by temporarily ignoring the docker-desktop package so you can update normally.

Honestly, I’d personally advocate for tossing docker entirely and migrating to podman which has its own podman-desktop GUI. Since it is maintained by red hat, you’ll always have the latest and greatest without weird issues.

Beyond that, I’d say uninstall this package and install docker without the desktop GUI according to the guide.

⚠️ NOTE: Docker Desktop is not supported, you will run into issues if you use it

That’s from the winboat GitHub page.

Not entirely sure what you’re trying to do though.