On Fri, Jun 21, 2013 at 8:57 AM, Anselm Lingnau < [email protected]> wrote:
> Sigh. I have no issue with libvirt/virsh. They are great, and I agree that > *if* we wanted something to do with virtualisation in »sub-LPIC-3«, then it > would make sense to go with them. Okay, that's better. You can even disagree with me, but I want to know why, and then I'll respect it as a peer. But you've gotta give something other than ignoring or dissing it without any info. ;) > On the other hand I'm by no means convinced > that virtualisation in general needs to go into »sub-LPIC-3«. > And I'm not arguing either way. I.e., what was bothering me most is the total lack of even mentioning libvirt/virsh once sub-LPIC-3 came up. You don't need to patronise me ... > It's ironic you state this, given some of your comments later ... Also ... are you sure on your licenses? Sometimes people get confused, and that's never good with licenses. I.e., some of the "connectivity" components are not. In any case, my point was, it doesn't belong as a consideration, at all. Let's focus on what comes in _all_ distros and has Upstream buy-in, especially those that are technology _agnostic_. Okay? It is true that the VirtualBox kernel extensions are not »upstream« but they > are reasonably easy to get running (much more so than, e.g., those of > VMWare). > Again ... I'm not here to discuss this. Has nothing to do with LPI. Use what you want in your classes. I do the same. That's not for discussion here. Do you get my point? I'm purposely "holding back" on my "individual viewpoints," to avoid _distracting_ from LPI Objectives. ;) They're included from the get-go in many popular Linux distributions ... Again ... I'm not interested in talking about what is "less proprietary" on the LPI-examdev list. If you want to have this debate, we'll have it off-list. In Debian GNU/Linux, for example, there are > various other interesting non-upstream kernel bits in additional packages > that > people install if and when they want them (can you say »nVidia driver«, for > just one popular example?), so, whoa, big deal. > Again ... do we cover this in LPI? Does it matter here? Discussing Debian Non-Free is as useless for this list as Fedora RPM Fusion or any other. What does it have to do with _anything_? As I said, *if*. I'm not convinced that we actually should. If we do then > libvirt/virsh is probably the way to go. > *My* point, if you'd care to listen I'm trying. But you're talking about VirtualBox and VMware, Debian Non-Free and other things. But I think you're missing my very relevant point ... and "patronizing" me ... I'm personally not hung up about the specific virtualisation infrastructure > that people use. Hence ... libvirt/virsh. Kinda ironic, given your posts, and then mine. ;) >From the standpoint of a LPIC-1 junior Linux sysadmin, it does _not_ matter what the virtualization infrastructure is. The senior sysadmin or architect chooses the architecture, and libvirt [1] abstracts the rest, with virsh being the most common CLI provided with every single distro. But here we go again ... I have had good experiences in LPIC prep classes with VirtualBox ... Again, what does this have to do with the LPI Objectives? But now I'm really questioning if you understand what libvirt/virsh is ... hence ... like VirtualBox is all I ever get to begin with – in which situation > libvirt/virsh is of precisely no use whatsoever. Ummm ... once you have VirtualBox installed, virsh works. The drivers are internal to the libvirt library. > Other people may have the same sort of good experience with libvirt/virsh > or, for that matter, VMware Player or User-Mode Linux. Ummm ... libvirt/virsh is _not_ a "Hypervisor." Libvirt is a library that abstracts the Hypervisor (and an increasing number of Storage frameworks) [1], and virsh is just a CLI front-end for common sysadmin usage. Again ... do you understand this? Or, as I hinted, I think you're actually "patronizing" me, to use your term? Which is great for them as far as I'm concerned. > I'm certainly not getting into a shouting match about how I should really > be > using libvirt/virsh in my classes. > I'm not saying what you should use in your classes. That's our "disconnect." I'm talking LPI Objectives. You want to talk non-LPI classes. I am purposely biting-my-tongue to avoid that tangent. Although I am now doubting that you understand what libvirt/virsh actually is. ;) But if that gets you to research, then so be it. I'm sure I'll get another e-mail about how you like it even more than me, and you know all about it and use it all-the-time. ;) -- bjs P.S. It really makes me question where, at least some, select people are coming from here, and if it's worth my bother to contribute new objectives if people aren't familiar with what comes in all distros? Why have standards that every distro supports, but users immediate assume or snub without stopping to recognize them? [1] libvirt internal drivers: Hypervisor and Storage - http://libvirt.org/drivers.html -- 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
