11:02 p.m.
Hi Michal,
On Mon, December 7, 2020 11:43 am, Michal Skrivanek wrote:
> 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.
[snip]
> +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.
As of several years ago, I don't think any of these options worked with
multiple, distributed (remote) users with different capabilities on the
same VM Host. Has that changed?
> 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.
I think there are enough users who want this configuration (or, gasp, are
actually using this configuration) that it might warrant a little more
testing. Yes, we understand that there will be times that we need to shut
down VMs and reboot the system, and those times can be scheduled (like
I've done). However, that WOULD require a little more support, to at
least have a recipe that works on a single-host hosted-engine solution.
For host cert renewal, that recipe didn't really exist.
[snip]
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)
Of course. (Personally, I think it should have been called 5.0 instead of
4.4, as it requires a full re-install to migrate from 4.3).
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.
Exactly. Some tested playbook recipes that allows a single-host
hosted-engine deployment to perform these operations is really what I'm
asking for. Yes, I know it will require rebooting. But reboot is much
less risky that re-install!
And for the record, after putting the new certificates into place by hand,
just restarting a VM was sufficient to get Spice to pull in the new
cert(s). So, technically, it LOOKS like I don't have to reboot the whole
system (although I plan to do that tonight) -- I could just shutdown and
re-run each VM.
HTH,
michal
Thank you for all your support and everything you do for this project,
Michal. We very much appreciate it!
-derek
--
Derek Atkins 617-623-3745
derek(a)ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant