Hello Fabian, maybe my answer to this mail is a little bit to late, i don't know.
Am 22.01.20 um 00:28 schrieb Fabian Thorns: > Dear all, > > I hope you all had a great start into the new year. This year we'll see a > series of new exam > releases, including the new LPIC-3 exams. Therefore I'd like to (finally :) > summarize the > discussion with a proposal. > > It seems to be agreed that there is a set of base technologies which are > seldom used on their own > (e.g. KVM), but instead are usually integrated into various other platforms > and tools (e.g. > Proxmox or oVirt). While we cannot cover too many details of the various > platforms, we shouldn't > expect too much knowledge regarding stand-alone use for the base technology > tools either. > Therefore I'd like to propose reducing the weight of stand-alone Xen and KVM > and instead add some > more container concepts, as described below. > > > * Reduce the weight of Xen from 4 to 3 > > - Change 'Understand the configuration of Xen nodes and domains' to 'Basic > configuration of Xen > nodes and domains' > - Change 'Manage Xen nodes and domains' to 'Basic management of Xen nodes and > domains' > > Would you keep 'Troubleshoot Xen installations' or drop it? We have this Discussion about Xen some time ago here in the List and and that Xen is not complete out of the new 305 Exam, good to see. From 4 to 3 is okay and i think 'Troubleshoot Xen installations' would i keep in. > > * Reduce the weight of Qemu from 6 to 4 > > - Change 'Understand QEMU configuration parameters' to 'Start QEMU instances > from the command > line' and 'Awareness of important QEMU configuration parameters' > - Change 'Manage QEMU instances from the command line, including using the > QEMU monitor and > managing snapshots' to 'Manage snapshots using the QEMU monitor' > I think a weight of 4 is okay. Maybe i am alone but must of the users i know uses qemu in combination with KVM, not only qemu to start a Virtual Machine. But this is my private experience i have make the last years. Maybe Somebody out there sees this in a different light ;) > * Increase the weight of VM Disk Image Management from 2 to 3 > > The current contents already justify weight 3. > > > * Increase the weight of Container Virtualization Concepts from 6 to 7 > > Here we should add some more contents regarding container standard formats > and runtimes. I'd like > to propose the following additions to this topic: > > * Awareness of the OCI runtime and image specifications > * Awareness of the Kubernetes Container Runtime Interface (CRI) > * Understand the principle of runc > * Understand the principle of CRI-O and containerd > * Awareness of podman, buildah and skopeo " Awareness of podman, buildah and skopeo" is a good point for the new Exam. I think at this time is enough for "Awareness". Maybe in a few years it look different with podman and docker, but how knows. > > * Increase the weight of Container Orchestration Platforms from 2 to 3 > > Again, here we should have already enough in the objectives to justify three > questions. > > Finally, these changes would bring both virtualization and containerization > to the same amount 25 > weights each. And these changes can easily be made during the last > finalization steps of the > initial item pool. > What do you think? I was in January at the Red Hat Forum 2020 in Darmstadt, Germany. One of the biggest Statement there was " Everthing, it is possible, put in a Container" So, with this experience i make it is good that the weight of both are equal. Nobody here can look ahead but at this moment i think the new 305 Exam is good to pass the next 5 Years. Dirk > > Fabian > > > On Wed, Dec 4, 2019 at 7:12 AM Bryan J Smith <[email protected] > <mailto:[email protected]>> wrote: > > On Tue, Dec 3, 2019 at 5:05 PM Bryan J Smith <[email protected] > <mailto:[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] <mailto:[email protected]> > https://list.lpi.org/mailman/listinfo/lpi-examdev > > > > -- > Fabian Thorns <[email protected] <mailto:[email protected]>> GPG: F1426B12 > Director of Certification Development, Linux Professional Institute > > _______________________________________________ > lpi-examdev mailing list > [email protected] > https://list.lpi.org/mailman/listinfo/lpi-examdev
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
