On Tue, Dec 3, 2019 at 5:05 PM Bryan J Smith <[email protected]> wrote:
> Have any of you actually seen ... > I keep having this conversation over and over ... Same concept here. KVM > and 'virt-manager' is *not* what Enterprises and even SMBs user in the > CentOS/RHEL world. Cockpit isn't either. ;) > I re-read some of my posts today, incluindg comments like the above, and I want to apologize for being 'abrasive.' I do this at times, and I need to find a better way to convey my viewpoints. > > It abstracts a lot of the internals involved in setting up complex things >> like a Ceph cluster. >> > > And oVirt (RH[E]V) is designed for 'hyperconverged' -- aka add a node for > more compute + storage. ;) > > Sure, if one wants to setup a full CEPH farm, to be used in various ways, > they can. But they don't have to, not for a long time. > > I.e., why might they want to? To get Origin (OpenShift) on oVirt > (RH[E]V), which is finally coming in Origin (OpenShift) 4.2-4.4 (about > time). Telcos are not only big into that, but that's what I did in HP in > 2014 -- HP Helion Open Stack Developer Platform (HP's CloudFoundry-based > DevOps on OpenStack -- 1 GUI to rule them all) -- at a major Telco here in > North America. > > >> So from where I am standing, it is something like Plesk or >> Virtualmin/Webmin/Cpanel/DirectAdmin/etc. >> > > And oVirt (RH[E]V), only the latter is 100% FLOSS. ;) > > The major difference of Proxmox to the RH-world is its orchestration >> called qemu-server that they use instead of libvirt: >> https://github.com/proxmox/qemu-server > > > Again, oVirt (RH[E]V) does _not_ use libvirt _except_ for the _small_ KVM > support portion. I cannot stress this enough. I couldn't have implemented > a 10,000 instance VDI solution in the US starting in 2012 without such. ;) > > Let me say that again ... oVirt does _not_ use libvirt for this, period. > It uses various added services -- e.g., VDSM. [1] > There is also AD and IPA authentication, including for SPICE connections. > 'virt-manager' doesn't do that either. > I could go on and on about the various services that oVirt provides. > > oVirt is a framework that only uses _basic_ (standalone) libvirt/KVM for > the Hypervisor interface, and includes so much more -- all FLOSS -- for SMB > and enterprise deployments. Same goes for so much "Enterprise > Infrastructure" built around RHEL, but *not* in "base RHEL" itself ... but > still 100% FLOSS. "base" RHEL is such a small subset now, and part of the > reason CentOS is very frustrating, because they build so little of Red Hat, > and rely on Fedora EPEL, which is becoming a 'leading edge testing ground' > (something I warned about in 2011). > > Red Hat doesn't like to 're-invent the wheel.' So when it sees a product > as 'insufficient,' it either writes or acquires something. That's where > 389 Server (fka Netscape Directory Server / iPlanet lineage) comes from. > That's where oVirt (RH[E]V) comes from too (acquisition). I just found out > today in a meeting with Red Hat (quarterly on-site meeting) that Red Hat is > going to open source IBM Cloud Manager. It seems IBM is wanting to start > open sourcing a lot of its proprietary codebases. > > So while I think Proxmox has significance, I don't see it as a standard >> like Docker. > > > I'm 100% fine with the FLOSS components being covered. I think it's worth > to include all FLOSS components that Proxmox uses. But non-FLOSS is a > problem. > > E.g., libvirtd ("d") for supporting VMware ESXi, et al. but not vSphere, > et al., proprietary frameworks. This is what I'm trying to figure out with > Proxmox. What I find extremely frustrating is that people have never used > oVirt (RH[E]V) and thing everything in "base" CentOS/RHEL is all that > people use. When I say libvirtd, vdsm, et al., I don't mean the > 'virt-manager' GUI. ;) > > Also I can't think what kind of questions we would be >> asking. The typical user/admin will hardly if ever use the console or be >> required to understand how Proxmox works internally. So the coverage >> could and should only be awareness and concepts. >> > > I'm a huge fan of commonality. This is Level-3 (300). We should be more > focused on the commonality of internals. If Proxmox is using KVM, it's > using libvirtd ("d") too. It's impossible not to. > > I think people keep looking at libvirtd ("d") as this 'simple tooling,' > when it's a library-service for general Hypervisor access. E.g., VMware > supports it for ESXi instances in OpenStack. It has nothing to do with > "virt-manager," that's just a "test GUI" for basic stuff. > > oVirt and you'll understand what I mean. It's awareness of multiple > solutions I'm concerned with here. Just like with only knowing OpenLDAP, > and never hearing anything else. We need to cover commonality, and expose > people to the fact that they need to know the underlying technologies and > components that they all use. > > - bjs > > [1] oVirt VDSM Developer Guide > - https://www.ovirt.org/develop/developer-guide/vdsm/ > > [2] Self-Hosted Engine (oVirt-M, aka RHV-M) > - > https://www.ovirt.org/documentation/self-hosted/chap-Deploying_Self-Hosted_Engine.html > > >
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
