On Mon, Dec 7, 2020 at 2:22 PM Derek Atkins <derek@ihtfp.com> wrote:

[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.

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.

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.

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.

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

Thanks for listening

Gianluca