Hi Michal, On Mon, December 7, 2020 11:43 am, Michal Skrivanek wrote:
On 7 Dec 2020, at 15:35, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Mon, Dec 7, 2020 at 2:22 PM Derek Atkins <derek@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@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant