[snip]
The main advantages of ovirt over virt-manager is the access-control and
remote-access capabilities. Specifically, I have several users which have
different access to different VMs and their consoles. Without providing
ssh access to the host, I wasn't sure how to provide that access in a
clean way via virt-manager.
I *used* to use vmware-server, and kept that running as long as I could
(on a single server). But that hardware was running long in the tooth, so
I migrated to ovirt because it gave me a similar web-based UI interface to
my users so it was relatively easy to migrate them. When I migrated 4-5
years ago, virt-manager was still in relative infancy and, IIRC, didn't
have much remote capability.
+1 here.
And I think developers should put more attention in single host environments than lastly done.
well, the truth is it is a corner case. I’m not saying it shouldn’t work but as Didi said a single host management was never the main goal. We’ve built oVirt around shared storage and DC scalability, that it sort of happens to work with single host is….nice, but it’s really not that typical. There are better options for desktop-like virtualization in OSS world, there’s virt-manager, there’s VM management in cockpit UI, gnome-boxes.
Derek explained very well what could be many common situations to have a single host environment and the reason not to use virt-manager and such.
At time there was the all-in-one and then it was deprecated/abandoned in favour of single host deployment.
yes. but it was never meant to be a real thing in a first place, it was created just for demo purposes so it can run on a single laptop.
Now due to perhaps ansible playbook or new logic in host upgrades it seems to see more and more messages about single host not supported.
it’s not intentional, just not tested enough so it keeps breaking. we really can’t test every use case in automation.
In my opinion to do a reinstall every minor update is not feasible.
The free version of ESXi could become a more appealing alternative in the near future for these kind of usages, with the risk of potentially eating away also the bigger shape scenario then.
Perhaps to support again the all-in-one effort could be a good approach.
all-in-one was awful, i’d rather fix those few little things around single host deployment:)
If you think it can get more attention I can open an RFE for revamping all-in-one or an RFE to provide a mechanism to have an host update itself through a locally executed playbook and then "acquired" by the SHE in a second time when exiting global maintenance.
I don't know the internals enough and I have not the coding skills, but I can support testing the functionality
I don’t think it would take too much attention, TBH. We’re still dealing with 4.4 and el8 complications (it’s still fairly early since GA of a major release)
What would make sense, I think, is to identify the actual issues/complications and do them differently, like indeed a special local playbooks or whatnot, or “special” hacks. And then document on oVirt wiki. But otherwise I do not really see them supportable - the amount of work to e.g. re-enroll certs on a running host is just too much to do properly, and everyone has a different level of “risk” they accept.
HTH,
michal