On Tue, Dec 3, 2019, 11:39 Markus Schade <[email protected]>
wrote:
> Proxmox has (at least in Europe) a substantial adoption in the SMB segment.
And it's definitely important that LPI address SMB and not just larger
Enterprises. No argument. I still deal with a lot of Ubuntu LTS (not just
CentOS), even Debian, although Debian has very large userbases too (huge
ones in fact).
Working at one of the larger hosting providers (for dedicated
> servers), we see significant use. These are primarily customers/people
> who have no or very small IT departments. So basically Proxmox offers
> them a free (as in beer) equivalent of VMware with a nice GUI that they
> can install on top of Debian.
And that's where I start to get concerned. ;)
We're talking the underlying FLOSS solutions and services that aren't from
Proxmox, and that's what we should focus on. When it comes to 'free (as in
beer),' that's really not what we want to get into.
oVirt (RH[E]V) and Origin (OpenShift) are complete FLOSS solutions, with
full frameworks and advanced APIs, support solutions, etc... Libvirtd
('d') is a _tiny_ portion of it.
I.e., I haven't had to do Cluster Suite (Corosync, Pacemaker, et al.) for
KVM host failover in almost a decade, because oVirt (RH[E]V) provides so
many other *d/*ctl solutions for network, storage. That's still required
for Proxmox v6 and a lot of 'front-ends' that expect people to setup.
E.g., people say things like 'libvirt' and 'cockpit' not realizing those
are _standalone_ (individual) server solutions. Enterprises and even SMBs
do _not_ use KVM 'raw,' or 'virt-manager.' That's like saying Enterprises
and SMBs use VMware Player for Servers -- they do not. Red Hat _never_
intended the _basic_ libvirt tools to be for anything but like what VMware
Player is used for.
Again, Enterprises or even SMBs don't use basic CentOS/RHEL. They use
_advanced_ infrastructure projects (and products) like oVirt (RH[E]V) that
has many daemons added, like VDSM, among others, built on RHEL. It's been
around a _decade_, fully FLOSS. [1]
Real World: I insert pre-created Hypervisor keys (oVirt/RHV-H), I load the
hosted engine (oVirt/RHV-M) manager, into systems, and ... boom, I'm up,
*exactly* like the equivalent VMware (ESXi ~ oVirt/RHV-H[ypervisor], and
vSphere ~ oVirt/RHV-M[anager]). [2]
Have any of you actually seen oVirt-M / RHV-M aka "Self-Hosted Engine"?
It's not 'virt-manager.' ;)
I keep having this conversation over and over, just like I used to on 389
Server (Red Hat Directory Server) last decade, when people said OpenLDAP.
"OpenLDAP is FLOSS!" Yeah, and "389 is FLOSS too ... but supports up to 20
instance multi-master replication per tree." And they're like,
"Replication? I don't use that. Too difficult to setup for LDAP" And I
roll my eyes (because they just nailed it why Enterprises don't use
OpenLDAP, but iPlanet/389 lineage). And now we have SSSD, IPA, et al. too,
this decade. ;)
Same concept here. KVM and 'virt-manager' is *not* what Enterprises and
even SMBs user in the CentOS/RHEL world. Cockpit isn't either. ;)
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
