Ahhh ... now this is the type of response I like to see. Real, technically-backed comments, with solid logic, focus on Upstream accepted with broad adoption and distribution.
My comments ... A) Creating, starting, stopping, etc... is going to be the most "basic operations," so should be looked at for LPIC-1 or 2 B) The most generic way to support all distros for the most "basic operations" is virsh via libvirt C) Hypervisor-specific details are still going to be unavoidable, so the question becomes whether we cover them in LPIC-2 or 3 (assuming not 1) D) Given LPI mitigates desktop objectives, and Virtual Desktop Infrastructure (VDI) really brings in a lot of other details (e.g., identity), I too agree it should be avoided As far as re-organizing the LPI program into new levels, beyond the administrative issues, I'd like to point out ... 1) I've always noted LPIC-1/2 has always tried to address the junior v. seasoned sysadmin, and LPIC-3 was the specialty level 2) There's nothing stopping LPI from adding specializations at LPIC-2, but that really conflicts with LPIC-3 at the same time 3) There's nothing stopping LPI from combining multiple LPIC-3 specialties into a "super specialty" or title 4) I don't see a 4th level used in other programs, usually just Associate/Junior, Professional/Seasoned and Expert/Specialist with the last often combining with several into Architect Just my views. On Fri, Jun 21, 2013 at 10:32 AM, <[email protected]> wrote: > ** > > Hi, > > > > With so many messages about virtualization coverage I can't resit voicing > my opinion. Feel free to disagree, please just don't repeat arguments > already made on this thread, I've read it all. ;-) > > The way I understand LPI principles KVM, Xen and LCX (containers) would be > tecnhnologies to cover, being open source and included in the most popular > distros. VMware and Hyper-V linux support would be off-topic, and any > sysadmin who understand a proper KVM setup using paravirt drivers would > understand poprietary hypervisor tools. > > libvirt et al would be a most, because support multiple hypervisors and > are on both debian and red-hat families of distros. But native tools (open > source, xend) for xen would also be a must. Qemu would enter as a > dependency for both kvm and xen on linux, but I don't see enough > justificative for qemu per se (without hardware virtualization and so > either kvm or xen) > > I think basis of Xen and KVm should be part of LPICP-2 because today most > small to medium environments use virtualizations. Small companies with a > single server run tree or four VMs, because it's easy and cost-effective. > Everybody talk about, and they are really a time-saver, bringing more > flexibility to the server environment. A LPICP-2 should at least deploy a > simple VM using virt-manager and virsh and be able to understand how it > impacts performance, security, upgrading, backup and disaster recovery. > > If this makes too much for LPICP-2, it's time to reevaluare: four levels? > Three tests for LPICP-2? It's not because the curent LPICP model has worked > for the latest 10 years and more that it'll continue working for he next > 10. As a candidate I wouln't mind more tests or more questions if they > reflect my daily job, and as a boss I'd focus on the results: if I need > pros with virtualization knoledge, LPICP-2 should cover them someway. > > vSphere, XenEnterprise and other closed source tools, no matter the market > share, would be off-topic. Leave that for the vendor certs. > > "Enterprise" and could stuff like oVirt, openstack, virtual switchs > should IMHO be a LPICP-3 expertize area, that is, it's own cert with a > LPICP-2 prereq. And by the way I don't think VDI (think spice, XenDesktop) > would be worth LPI topics by now. > > []s, Fernando Lozano > -- 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
