[sf-lug] doing test installations into a virtual machine (was: (forw) Re: SF-LUG meeting notes for Sunday 02022020)

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] (forw) Re:  SF-LUG meeting notes for Sunday 02022020
> Date: Sun, 2 Feb 2020 23:22:34 -0800

> Bobbie wrote:
>
>> So far I have tried following the directions at this site but have
>> encountered problems due to various causes but mainly with the time it
>> takes to do the sequence of events involved in the installation.
>> <https://dephace.com/how-to-build-a-hacking-lab-with-virtualbox/>

And ... why follow semi-random "advice" on The Internet?
If you're running distro X, you install the relevant virtualbox
package(s) PROVIDED BY YOUR DISTRO! (and use the documentation from one's
distro).  If your distro doesn't provide/package VirtualBox,
next best bet would be from the source (alas, not as in source code) -
Oracle: https://www.virtualbox.org/
And follow the relevant steps/documentation.

Might also want to consider other virtual machines, other than
VirtualBox ... though there are generally advantages/disadvantages
among them.  In part:

VirtualBox - easier to get going (point and drool^Wclick),
cross-platform (host can be Microsoft Windows, MacOS, Linux (, ...?))
mostly a play(+?) with it on one's desktop/laptop, but rather to
quite solid and functional (and relatively easy).
No live migrations or the like, but can always copy over cold images
Not OpenSource,
fails DFSG: https://www.debian.org/social_contract#guidelines
Oracle, evil ...

KVM/qemu-kvm (packages naming varies, the KVM and QEMU projects merged,
so packages may be called kvm, or (e.g. on Debian) qemu-kvm).
KVM uses hardware virtualization for near-native performance,
QEMU is software virtualization only, no hardware virtualization
support, QEMU supports non-native architectures, KVM does not.
Other than that - same, typically same package(s) (mostly - though
often one adds more packages for (additional) foreign architectures)
and most of the time hardware virtualization support is default
and enabled if available
rock solid enterprise class (very widely used, e.g. "cloud" and the like),
can do live migrations (move guest VM to some other parent host while
it's running!)
not as simple as VirtualBox to get started, but not horribly complex.
passes DFSG (OpenSource).
The BALUG VM which host most all things SF-LUG besides it's list,
runs on qemu-kvm on Debian.

Xen - uses paravirtualization - saves some RAM and other resources,
at the cost of guest/host kernel entanglements (not as separate and
independent),
newer (non-ancient) Xen also supports hardware virtualization
rock solid enterprise class (very widely used, e.g. "cloud" and the like,
AWS used it in past and may still be using it)
can do live migrations
not as simple as VirtualBox to get started, but not horribly complex.
passes DFSG (OpenSource).
SF-LUG's non-list stuff used to run on Xen before we converted it to
qemu-kvm.

(there are others, but those are probably the most relevant for fairly
high functionality and free as in gratis ... some VMware stuff might
also qualify - but I've not looked closely at that in quite a while)

Also, libvirt & friends can make managing most or all of the above
easier.  It provides a highly consistent common interface for managing
the VM infrastructure - regardless of what the underlying VM infrastructure
is.  So, no need to relearn a totally different sent of VM management
commands just because one changes VM infrastructure - or even runs
multiple VM infrastructures.  Related utilities also provide a nice GUI
management interface - if/when one might want or "need" to use such,
so much functionality - and much of the ease of it, can be made relatively
similar/"easy" as VirtualBox's point and ...

> Also, you really shouldn't need a special Web page full of instructions.
> VirtualBox in my experience doesn't really need much in the way of
> documentation.

Yep, not too much, ... and not some random Internet advice web page.

SF-LUG non-list stuff has been on virtual for ... geez, long time,
maybe a decade now?  Would have to dig through archive(s) or log(s) to see
how long it's been.  Hmmm, maybe fast peek ... yeah, over a decade.