LXLE on Librem Hardware For Faster VMs?

I need the flexibility of VMs, but with reduced hardware demand. (The fans are screaming and the system slows to a crawl when using VMs.)

I’m considering this solution:

Host: Lightweight distro: LXLE
VM manager: Virtualbox (because I could get USB pass thru to work).

I’m hoping the LXLE distro will run the VMs with less overhead, and I can do the bulk of my work inside a VM specialized for the task.

Before I dedicate a good day setting this up to test it, for LXLE users running Librem hardware, a few qs:

Are you able to get Virtualbox to work?
If so what kind of performance are you seeing running your VMs vs. bare metal?

Do you have a link to LXLS? All I can find is LXLE which is based on Lubuntu with LXDE and LXDE’s successor is LXQT.

I am not an expert for virtualization but would not expect big differences in performance between up-to-date distributions on the host. Of course some DE’s are slimmer than others.

I think most important is the hardware support of virtualization, especially the CPU. I would expect all modern desktop CPUs to have virtualization support. You should check this with lscpu and you should check if those features are enabled in the BIOS.

When it comes to the guest systems I would think that there may be significant differences between ordinary distros and distros that where specifically designed for virtualization like Alpine Linux. Also if a guest system starts quickly maybe it doesn’t have run all the time and can be started on demand.

Also you could ask yourself if you really need everything in a full blown guest OS VM or if some subsystems can be run in containers with podman or whatever. That would probably reduce the burden.

https://podman.io/

The next time I will setup a VM I will try Gnome boxen (which is easier) or virtmamager (which has more options but pitfalls, too). I can’t judge if that will make a difference in performance.

If you run many VMs maybe a hypervisor or a virtualization platform like proxmox would be interesting to you, but I have no experience with those.

Just trying to help.

1 Like

Sorry. My mistake. LXLE, not LXLS.
https://distrowatch.com/table.php?distribution=lxle
https://www.lxle.net/

Downloading Alpine now. We’ll see.
Podman… this is a new concept to me. Drilling down on it now.

Be aware that Alpine’s package management tool is apk not apt.

Three lightweight operating systems inspired by Qubes OS:

https://spectrum-os.org

1 Like

I updated my post. Its hypervisor not superviser of course lol.

And because the question “Which is the best container for Linux?” has been in my head for some time I started a new thread.

1 Like

Well, I’ve been making the switch from Apple to Linux for some time. And while I heard of Snap & Flatpak… this is really the first time I’ve heard of all these containers.

Which has me wondering, what else am I missing?

Is there the equivalent of portable containers? Meaning, I have a self-contained app, that saves all its state inside the container, and not scattered through the file system.

So as long as I copy the container with the app in it, I can run it on any other machine, and still have all the data self-contained in the app I had on the other machine?

I know there are portable apps… but ideally I could make any app portable with some kind of container engine, that would give me the flexibility I’m trying to get with VMs.

Anything like this in the Linux sphere I’m missing?

You can use Linux perfectly without containers. Whenever I need a new program the first thing I do is look into the the repositories of the classical package managers of the installed distro like apt. When I don’t find a software there I look out on the internet and may have to install a software manually. Which most often simply means unpacking, rarely running a shell script and installing dependencies (packages or other stuff a program needs to work. So I do manually what normally the packet manager does for me.

One reason not to install a program from the repos is if I need a newer version, which is rarely the case. Or I need different versions in parallel. Depending on their release model some distro’s packages are more up-to-date than others.

So we are still at ordinary programs which run as processes and have a certain degree of separation. Each process has its own memory but they share the filesystem as an example.

With a VM you have a virtual computer with OS and programs. You can start multiple in parallel and have a great degree of separation. A malicious program would have to break out of the guest OS and the VM to get to the host OS. But VMs have a relatively big footprint, which might considered to big for separating small programs which aren’t security sensitive.

There is something in between and that the OS-level virtualization alias containers. Be aware that “container” is a pretty general term for something that contains something and is used in many contexts in IT and out of.

Containers do not need to run a guest OS and still provide a certain degree of separation between programs (which depends on the chosen container). Usually each instance has it’s own separated view of the filesystem and maybe other resources. Containers can be run many times in parallel, can be starter and stopped quicker and have a lower footprint coompared to VMs.

Also container are convenient for developers because everything what a program needs e.g. libraries, databases etc. can be included in the so called container image. So a container and its developer doesn’t rely so much on the OS package management e.g. to provide the dependencies in the needed version. A developer can provide a new version quicker without having to wait for the OS to provide updated dependencies. The dev can simply provide everything up-to-date in an updated version of the container image.

Unfortunately that is not only a pro but a con and point of critic at the same time, because it would be naive to believe that every container will be updated with security fixes. Some may still be carrying vulnerabilities around while the OS packages already have been updated.

Also every container might include e.g. library L and so there are many copies of the same thing occupying storage and memory and burden the system. Some containers can share common stuff to lower this con.

VMs and containers can both be useful for simple one user desktop systems up to huge cloud computing infrastructures.

The question is: what tasks do you want to separate and why?

#1: Security:
Sandboxing, like Qubes does. (Unfortunately, Qubes was too resource heavy.)
Keeping any malicious code self-contained in its box.

#2: Portability:
Self-contained encrypted boxes that hold the state for the software it runs. I can just copy the box to another computer, mount it, access the contained software and have it run like it did on another Linux machine.

#3: Speed/Optimization.
I would like some environments optimized for different contexts. Like online research. Setup a lean machine that will run browsers and graphics heavy charts as fast as they can be run.

#4: Privacy, anti-forensics:
Data is contained within encrypted boxes.

#5: Flexibility:
The flexibility to clone/throw away a box as needed for a task.

I’m trying to get away from a resource heavy monolith machine that tries to do all things, with data scattered all over the place through that machine.

Ideally I can keep all my workflows on a few USBs/SSDs, then plug & play.

Software:
Journals
Chat/collaboration
Browsers
Vscode
Macros/automation

Context:
Online research
Writing
Journaling
Data archiving
Coding
Collaboration

Why not Qubes?

I think she said too resource heavy

2 Problems. Resource heavy, and I had an issue with the Ethernet sharing the USB ports. I tried. I really did. But just could not get it to work on this hardware setup. If I was using Wifi it would likely have been fine. But I don’t use Wifi (or any wireless tech for that matter).

Forgive the newbie Qs, but I’m still wrapping my head around how to best use containers.

In practical terms, I want to sandbox the browser from the rest the system. Ideally all bookmarks, passwords, history, cache is self-contained in sandbox container of some kind. Currently I’m using Slimjet. How would I move Slimjet into a container and sandbox it?

I want to take my entire journals layer inside an encrypted vault. I’m using Standard Notes and Libra Office for journaling software. How would I self-contain this software inside a vault?

I want the chat and comms apps sandboxed and in self contained vaults. Currently that means Keybase and Wire. How would I get Keybase to work inside a container?

I seem to be missing a step in this abstraction.

I would go for Podman (being a Fedora user I came across it earlier than most) and I prefer it to Docker . .

I don’t remember all details but what I remember is that I did read negative things about Docker and flatpak and positive stuff about podman. That’s the reason I mentioned it as an example abhove in the thread.

But I never used OS-level virtualization alias containers, yet. Keep that in mind. I am on this adventure myself. I will probably simply take one and try it out, when I got new HW or reinstall my server.

Out of my understanding it works like this:

  1. Choose a container system and install it.
  2. Get a container image or package by
    a) downloading an existing one from the internet (e.g. dockerhub)
    b) creating one
  3. Run the container

I think ideally step 3 doesn’t need further configuration but I imagine that sometimes one want to adjust resource access or set quotas for storage, memory or CPU time. So the main work is in step 2b.

That is what I imagine and it may be wrong.

1 Like

Just to clarify before I blow any unnecessary time learning this: If I use Podman, and make a container for Slimjet, the container will have all the browser data, and I can operate the container off a USB, and all my browser data will be contained in the container?

That’s a good question and actually I don’t know. I think sometimes it’s wanted to keep data longer than a container and sometimes both should be thrown away together so it probably depends on the way you create or configure the container image.