On Wed, Aug 1, 2018 at 2:49 AM, Kenneth Peiruza <[email protected]> wrote: > IMHO it's nice to know it but quite useless to be able to determine it from > within the VM, mostly because it only matters if you want to add specific > drivers for the hypervisor.
I would strongly disagree in all the environments I've worked in of thousands of instances. Most are a mesh of various in-house installs (even if deployed completely automated), vendor "appliances" (including VMs and Containers), etc..., and junior admins will likely be in an SSO environment, where they will consistently touch systems on any given day they have _never_ seen before ... even if they've been there a few months. Heck, I even had the case of SSH'ing to a system, and quickly finding out it was Windows. That quickly led me to find out it was yet another "appliance" running under yet another "hypervisor." Now I don't expect a Linux certification to someone to identify that, but that's just yet another example of how the "real world" is. Which means we need to have junior admins _know_ how to figure out they are in a VM instance, container, etc... > if it's a cloud instance, it's already done, and if it's a private > infrastructure, "you" already know it, and if it's a container you don't > need anything specific inside it. Most of these systems in an Enterprise environment will have been deployed _before_ the junior administrator every put their hands on a keyboard at the facility. So we should _never_ assume the administrator "deployed" those instances. Again, that's the "real world" in my view. And when you reach thousands of instances, it can get really crazy. Especially if server hostname nomenclature is not strong. As always, my views of what a "junior admin" should know may differ from others. But they are based 100% on actual environments. I don't share otherwise (or I will disclose such). - bjs -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
