Hello, My comments are inline:
On Jun 21, 2013, at 10:11 AM, Bryan J Smith <[email protected]> wrote: > 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 LPIC-1 or 2 they are VERY basic. Everyone needs to know how to do them. > > B) The most generic way to support all distros for the most "basic > operations" is virsh via libvirt Agreed. However, knowing ovirt/RHEV/Openstack GUIs are important as well. > > 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) 2 or a speciality of 3 but keep it to KVM, Xen, OpenVZ, etc. and also cloud layers such as OpenStack. > > 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 We cannot avoid identity but that should be part of a security specialization. > > 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 I do not see a forth level either but multiple specialty levels. Yet, since virtualization is a must then put the basics lower down for KVM and make openvswitch, migration, etc a speciality. Best regards, -- Edward L. Haletky President AstroArch Consulting, Inc. http://www.astroarch.com/ Author of VMware vSphere(TM) and Virtual Infrastructure Security <http://www.astroarch.com/?page_id=268> > > > 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 > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. _______________________________________________ > lpi-examdev mailing list > [email protected] > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
