11:43 a.m.
On 7 Dec 2020, at 15:35, Gianluca Cecchi
<gianluca.cecchi(a)gmail.com> wrote:
On Mon, Dec 7, 2020 at 2:22 PM Derek Atkins <derek(a)ihtfp.com
<mailto: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.
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
Thanks for listening
Gianluca
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/IXXAXY7IMAW...