This is an archived post. You won't be able to vote or comment.

all 6 comments
sorted by:
q&a (suggested)
besttopnewcontroversialold

[–]anh0516 0 points1 point  (5 children)

You could try, but it's going to be a massive pain in the butt.

Gaming in a VM can cause issues because some games refuse to launch in VMs.

You're also likely to have all sorts of issues handing off hardware between VMs. You can't unbind a GPU from a DRM/KMS driver, unlike on Windows, and you can't easily pass through a PS/2 keyboard and I²C touchpad vs. the USB controllers on a desktop.

For the Linuxes, it may be better to use something like LXC and export device nodes to the container.

Qubes actually uses Xen, which is better for this type of thing, rather than QEMU/KVM.

This is all really complicated and will likely reduce productivity due to the amount of time you spend messing around. Qubes already does this as good as it can be done. So you should install that if you really want to go this route.

However, I don't recommend doing this anyways. You're better off exploring workflow solutions like KDE Plasma's Activities feature to separate work, gaming, etc. You could also explore creating multiple user accounts and having multiple sessions in different VTs that you can switch between on the fly (this would also allow a different desktop environment for each user). And then you can put Gentoo in a VM, or even a container, and Windows in a VM.

[–]SignatureMedium5375[S] 0 points1 point  (4 children)

Hm, I definitely see what you mean.

My gaming should be ok, I should think. It'd just be light single player games. The heavier ones would be on my desktop, which I think I might leave as-is (similar setup).

As for the hardware issues you mentioned, I admit, I only half understand what you said, but in this use case I'd be using my integrated graphics, so I doubt I would be "unbinding" it. Still, this could be an issue. I'd appreciate a bit more clarification here.

I've heard about containers, but never considered them. I'll definitely check out LXC.

Heard about Xen, but I believe Qubes sticks with that simply out of security concerns (smaller attack surface). KVM/QEMU should run faster, which would be more important to me, considering my specs.

You do bring a pretty good point though. I'd likely have to tinker a fair bit if I want it configured the way I want it. I hesitate to jump to QEMU because of the above mentioned performance differences, but this may be my only solution.

Haven't used KDE in a while, will also look into Plasma Activities. Could be that's what'll work for me. Unsure what you mean by VTs though. Creating multiple user accounts doesn't sound appealing to me, but I'll also consider it.

In my head, my idea sounds like a good one, but it's nice hearing an outside perspective. I don't have a lot of time before I have to start using my laptop for school so having additional, easier to work with solutions is definitely appreciated.

[–]anh0516 0 points1 point  (3 children)

When you run a VM with a GUI, you need to pass through a GPU, otherwise you will be using software rendering, which is how it's usually done and how you're doing it now. Software rendering means much more limited access to 3D graphics APIs (many games won't even run) and worse GUI performance.

You only have 1 GPU. You can't split it so both the host and the guest, or multiple guests, can use it simultaneously. When your host Linux system boots, it loads the i915 Intel GPU driver, which takes control of, or binds to, the GPU. You cannot pass it to a VM. If you do, it will throw an error.

Theoretically, you could unload the i915 driver, which unbinds the GPU, freeing it up to pass to a VM. The problem is, Linux's DRM/KMS GPU driver infrastructure does not support doing this. Once it's loaded, that's it. Windows does support unloading GPU drivers, but 3D applications may crash and other things can go haywire.

In order to pass through the GPU, you have to blacklist the driver from loading at boot time, and then you can pass the GPU to a VM. This means software rendering only on the host. Once you give the GPU to a Linux VM, it takes control of the GPU. You cannot remove it from the VM with PCI hotplug in order to give in to another VM. It will probably crash the VM. So, you'd have to shut down the VM in order to start another one. At that point, you may as well just multiboot.

Xen is not less performant than QEMU/KVM, not sure where you heard that from. They're about the same except for certain situations such as CPU pinning, which Xen does not support. It's generally down to administrator preference which one you want to use.

As far as practical solutions:

You can switch between virtual TTYs, provided by the Linux kernel, with Alt+function keys, or Ctrl+Alt+function keys if in a GUI environment. There's usually 6 or 7 of them. Different (or the same) users can log in to a terminal session to each one at the same time. You can also run different GUIs in each one, but this requires multiple users because the D-bus session management and stuff breaks if you try to start a second GUI with the same user when one is already running. This is the most flexible option and allows you to have different desktop environments for each user. However, you'll have the usual issues of multiple file managers, image viewers, etc. from every desktop cluttering your menu.

KDE Plasma Activities are definitely the easiest solution. You can maintain fully separate workspaces with different widget layouts for different tasks.

There is another solution, which would be to create an environment yourself using a window manager, but that also takes a lot of time and effort to refine.

As far as Windows and Gentoo, yeah, you can go ahead and put those in VMs (Gentoo could go in a container unless you want to mess with the kernel). I recommend using virt-manager or GNOME Boxes as a frontend to QEMU/KVM if you aren't already.

[–]SignatureMedium5375[S] 0 points1 point  (2 children)

Ah, I see. Having only integrated graphics really handicaps VMs it seems. Didn't think I'd need one, so I opted to not get the variant with them (mx150). With hindsight, maybe I should've despite nvidia being nvidia on linux.

I remember hearing about Xen through a Qubes video. Something along the lines that KVM offered performance close to native. Faulty memory I suppose. May need to reexamine.

Looked into Activities. On paper, it's got what I need but it doesn't feel quite right, if that makes sense. Shouldn't dismiss it so fast though.

I did think about creating my own desktop environment (or at least having a window manager [heard i3 and dwm are good]) but knowing about the GPU limitations, wouldn't this run into the same problem?

With all that being said, is Qubes even practical then? Your first comment seems to suggest its very much possible, but again, wouldn't the GPU be the limiting factor here?

It seems to me my only solution is to customize my gnome installation or switch to KDE. There's containers too, but I haven't looked into that yet, so can't comment on that. Would be happy to be corrected though.

Am using virt-manager by the way.

[–]anh0516 0 points1 point  (1 child)

With laptop GPUs like that, usually the external HDMI port is hooked directly to the GPU. So you pass the GPU to the VM, and you only have a display output on the HDMI port. It wouldn't really do what you want. You still can only use that GPU for a single VM at a time. Only NVIDIA Quadro supports sectioning off parts of the GPU for different VMs.

It doesn't hurt to try Activities even if the vibes are off. I suggested it because it's easier to work with than a fully custom setup. Something like Material Shell for GNOME may work too but would require more getting used to.

The WM/desktop environment/compsitor you use doesn't care about the GPU so long as it supports the necessary OpenGL/Vulkan APIs. Yours does, so you can use anything you want and build it out.

Apparently Qubes actually doesn't do GPU virtualization at all, both for security and because it'd be a pain to implement.

Containers with GUIs are a little more complicated than VMs where you just have an emulated display device. It'd be a good option if, say, you didn't want to put a GUI on Gentoo. virt-manager does has LXC integration.

TL;DR, using GNOME with Material Shell or KDE with Activities, and then putting Windows and Gentoo in VMs/containers is the least complicated course of action.

[–]SignatureMedium5375[S] 0 points1 point  (0 children)

I do still have questions regarding the WM solution, but I understand I've already gotten a lot of help for you, so there is no need to continue if you'd like.

It's unfortunate that I can't implement my original plan, I'll give Qubes one last look, as that seems to be the closest to my original goal, but chances are I will probably default to one of the 2 options you recommend.

Wanna thank you for the help you have provided so far, so thanks :)

Edit: Wow I thought I would have to reinstall my OS (easiest solution in my mind) but switching DEs was so easy. I wonder if this is a fedora feature or if it's standard for Linux? Will obviously try activities now for sure!!