I’m looking for a robust and reliable virtualization platform for my Rocky Linux servers. So far I have some experience with Proxmox under Debian, which runs very nicely, except the security update cycle is too short, Debian being Debian.
I can manage KVM/libvirt OK on the command line and run a few virtual guest systems on a Rocky Linux 8 hypervisor. But my approach is quite simple and bone-headed.
Now I wonder if learning a tool like oVirt (and installing it on a Rocky Linux server) would be worth the hassle.
With Proxmox it’s possible to “spread out” the hypervisor against several nodes to gain some redundancy. Also, Proxmox has a very intuitive solution to make backups of running VMs (PBS, Proxmox Backup Server).
In short, I guess I’m looking for a Proxmox replacement for the Red Hat world. Would oVirt be a good solution for this ?
I can’t answer that question since I’ve used only the KVM/libvirt, which I mainly manage with virt-manager.
I’ve had more than one host and have used live migration of the guests so that I could update&reboot each host without stopping the guests. (Explicit migrations; no automated HA.)
Thanks, that sounds interesting. For the moment, I’m also managing KVM/libvirt with virt-manager.
Can you recommend some documentation for the live migration like you describe it ?
Alas, I did learn to do it over a decade ago and have forgotten how I did figure it out.
Both ‘virt-manager’ (GUI) and ‘virsh’ (CLI) can do it. The transfer is via ssh or via libvirt’s(?) own protocol.
Essentially, the definition of VM (the xml dump) is copied first, then destination allocates RAM for VM
and content of RAM is copied over. Finally, VM in source is paused, final resync of RAM, VM in destination “continues”, and VM in source vanishes.
For all that to happen, both hosts must offer same resources, e.g. network interfaces and storage volumes. (Also, VM must require CPU features that CPU’s in both hosts have.)
Another (recent) was that up to el8 the libvirt had QXL/spice, but not in el9; had to shift to VNC before migration.
I had both hosts connect to same iscsi-volume (on SAN). Therefore, VM guest could see same filesystem in indentical path. Obviously, letting more than one guest mount the filesystem simultaneously would be disastrous.
I can’t recall whether I have ever tried live migration, where the content of storage should be copied too; might not be possible.
I have done “non-live” migration for such. Did stop VM in one host, copied definition (rsync) and content of volume (dd over ssh or netcat) to another host, and started VM there.
Forget oVirt. Last time i used it, it was a PITA to have a simple thing like the web console working. Which is supposed to work out of the box in any kind of hypervisor management tool. Not only that, but the project is discontinued. And rightly so, i’d say.
For just some VMs, yeah virt-manager works great. I install a X server on my windows desktop for using it.
It is not fair to say the project is discontinued. Even though red hat decided to pull development efforts away from it, there are still dedicated folks spending their free time working on it. Last release was in december 2022.
Yep, what is discontinued is Red Hat Virtualization, which was in effect oVirt. oVirt is still valid as a project so not discontinued.
Red Hat have decided to amalgamate the virtualisation side of things and add it to OpenShift. So, instead of running VM’s on Red Hat Virtualization, it can be done under Red Hat OpenShift Platform. This is most likely the reason why Red Hat Virtualization has gone EOL.
Red Hat has deprecated the ‘virt-manager’ too, already in RHEL 8. There was even fear back then that RHEL 9 won’t have it. RHEL 9 does have ‘virt-manager’, deprecated. Apparently the ‘cockpit’ still lacks too much functionality to suffice for all.
Red Hat has discontinued the support of ‘btrfs’ and does not support ‘zfs’, do they? Those are not “dead projects” are they?
The only question is how feasible are those to use?
(EPEL and ELRepo have plenty “not in RHEL” content …)
Red Hat discontinuing KDE, virt-manager and Btrfs in favor of GNOME and Cockpit makes me wonder if non-technical folks at the company make all the technical decisions. #facepalm
