Thank you all for your responses.

On Monday, 24 August 2020 13:02:56 BST Rich Freeman wrote:
> On Mon, Aug 24, 2020 at 6:57 AM Neil Bothwick <n...@digimed.co.uk> wrote:
> > On Mon, 24 Aug 2020 11:50:42 +0100, Michael wrote:

> > > I have a number of VBox VM systems, some with active software licenses
> > > running on them and the VBox-bin is a low-maintenance and convenient
> > > way to run them. I'd prefer to avoid emerging a non-bin VBox.  Is there
> > > some way I could keep older packages running in Gentoo, until more up
> > > to date versions appear again in the tree (if ever)?
> > 
> > Copy the ebuild to a local overlay and add app-emulation/virtualbox-bin
> > to /etc/portage/profile/package.unmask.
> 
> You would probably also want to grab a copy of all the distfiles and
> keep them safe, because they'll disappear from the mirrors.
> 
> Note that this is really only a stopgap.  As packages that require
> python 2.7 are removed from the repo, we may see more and more core
> python packages removed as well over a longer timeframe.  It will
> probably become increasingly less practical to continue to use python
> 2.7 as a result.
> 
> You could in theory move all of this stuff into an overlay.  As such
> they will probably work "forever," but you will end up shouldering all
> the work around maintaining security, compatibility, etc.

I'm pressed for time presently and adding to my list of maintenance 
liabilities is the very thing I'm trying to avoid.  ;-)


> I would encourage using this as an opportunity to transition to something
> else.

Yes, good point.  My workaround has been to look for MSWindows versions of any 
needed/desired applications and run these in a VM, or keep a couple of older 
binary distros in QEMU images.  The VBox-bin was my preferred option for 
production PCs, because it required a short emerge time (VBox-bin plus VBox-
modules) and little disk space taken up.


> On a side note, I've used VirtualBox in the past, and it is pretty
> simple to use.  However, you might find KMS a much better solution
> all-around.  Virt-manager is a package that wraps a nice GUI around
> it, and it isn't too different from Virtualbox.  It is a little more
> complex in that it is more layered - you could stick your VMs on Ceph
> block storage or iSCSI or whatever, or build your VMs with
> virt-manager and run them from virsh from the command line.  One key
> feature is that the kernel layer of it is built into the upstream
> kernel and it is 100% FOSS, so you have a VERY robust level of
> support.  The complexity comes from the fact that
> kernel/userspace/UI/etc is all separated into different packages, but
> emerge virt-manager should give you everything (you might need to
> enable KMS in your kernel as well, and maybe set up networking).

I may give virt-manager a spin, because the users will require a GUI manager 
to launch VMs, but then if I start emerging packages at large I could emerge 
VBox from source instead.  On my personal machine I just run QEMU, but I find 
plugin/unplugin USBs and other hardware via the QEMU monitor console to be 
rather clunky.  I've stayed with QEMU over the years as a more minimalist 
solution.  I preferred it as a more direct and simple solution to multiple 
virt layers, APIs and what not.


> I'll also note that 95% of the time when you're using a VM running
> Linux you're probably better-off using a container.

I use QEMU to run full virtual OSs - MSWindows, Android, other Linux distros.  
A container wouldn't do this - but I have been thinking of deploying 
container(s) to sandbox/isolate specific desktop applications like e.g. Skype.  
It's just that I haven't yet invested the time to learn and try LXC/LXD/
namespaces and a plethora of management apps and frameworks for them.

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to