On Fri, Jun 21, 2013 at 8:47 AM, Edward Haletky <[email protected]> wrote:
> Gotta Chime in Here... > If there is going to be a virtualization sub exam it must minimally cover > the following: > libvirt/virsh, > Remember, while libvirt/virsh can be extensive and complex, "virsh 101" can literally be LPI 101. The idea behind libvirt was and still is, make the Hypervisor and Storage irrelevant. The drivers for each are built-into libvirt, and it's usually just a matter of rebasing the version to get new functions. Libvirt's CLI is "virsh" and works for most everything, especially the "virsh 101" stuff (e.g., create, start, shutdown, etc...). From a GUI standpoint, I guess the "virt-manager" and similar solutions fit. Unfortunately, Libvirt's "advanced management" GUI, "oVirt," has failed to get any traction as so many entities are into building their own, "value add" (non-open source) management solutions, and have not waivered. > qemu, > openvswitch, > openstack > Whoa! I know "OpenStack" is a big buzzword right now. I mean, even Fedora maintainers catapulted Red Hat to #3 maintainer status in Essex before most anyone in Red Hat knew, and now Red Hat is the #1 contributor to OpenStack in Grizzly and it dominated Summit last week -- from keynotes to presentation. But when you say "OpenStack," you're really talking a _lot_ of different components. [1] [2] Do we just tackle Nova and Networking (fka Quantum)? I assume you want the later since you mentioned "Open vSwitch." Plus I assume Dashboard should be considered. Or do we start involving deployment, imaging and storage, which means Glance, Cinder and Swift? It's kinda hard to cover OpenStack without covering deployment and images. Swift file and object gets interesting as well, with countless backings available (e.g., Gluster's UFO is just one). And what about Keystone (identity)? Plus, we also run the chance of "bias." I.e., as IBM pointed out at Red Hat Summit, 95% of OpenStack deployments are on KVM. > virtuoso (at least the difference between it and kvm) > I'm really confused on this one. Virtuoso and KVM aren't even the same "type" of Technology. And if we're going to talk Virtuoso, we're going to be comparing _hundreds_ of different management frameworks. ovirt > Unfortunately, unlike libvirt and the virsh CLI ... oVirt is KVM-centric. Again, this is not because oVirt wasn't designed for multiple Hypervisors, far from it. oVirt was released with KVM, VirtualBox and Xen specifically in mind, with the hope other vendors would join in. Unfortunately Citrix-Xen and Oracle, respectively, had no interest in making an open source GUI and management framework that would compete with their closed source offerings. So oVirt can be considered largely KVM-only, because only Red Hat makes its complete management framework for Hypervisor, Storage, etc... infrastructure (e.g., RHEV, RHS, OpenStack, etc...) open source. And no reason to go down into a Red Hat-only stack, even beyond duplication. paravirtualized drivers > Which get Hypervisor-specific. At most, if we go here, we'll have to limit it to those that have full, end-to-end, Upstream buy-in just to contain the sprawl into hundreds of options. E.g., pretty much KVM and Xen at this point, since Linux Container technologies and options don't use paravirt drivers, of course. > Specific packages: > virt-* packages > Which are libvirt. > fence-virtd package (why do you need a virtualization fence) > > open-vm-tools (vSphere specific but important) > Seriously? You're kidding me? We're going to "open up the can'o worms" with that, things that aren't Upstream. Furthermore, doesn't EMC already have its certification? I.e., even putting my alleged "purity" and "bias" aside, don't go down this vendor-specific stack any more than RHEV. Instead ... why don't we focus on "upgrade" and "boot-time" integration/rebuild general concepts? > If you leave out any of those in favor of Type 2 hypervisors such as > virtual box you are missing the entire point of "server" virtualization and > real virtualization within an enterprise. > It is not about 'easy' it is about 'certification' a certification on a > type 2 hypervisor is similar to a certification on Microsoft word, glad you > know the app, but I really do not care. I want a cert that covers SERVER > virtualization. > I make no such case in either direction. I only point out that "libvirt" is the "C library" of virtualization support, and "virsh" is the CLI, built into every Linux distro. > I.e Type 1 hypervisors of which KVM and Xen are such. Cover those topics > make the cert worthwhile to anyone in the virtualization community. > I would rather put it in terms of "Upstream" buy-in and inclusion. If VirtualBox and others were completely Upstream and supported, I'd have no problem covering them. But given how VirtualBox still has dependencies for much functionality, and Oracle is not supporting libvirt developments well, they will likely never get there. -- bjs [1] http://en.wikipedia.org/wiki/OpenStack#Components [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/2/html-single/Getting_Started_Guide/index.html#idm85632832 -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
