4.3 is hitting RAM limits earlier than in 4.2

General Discussion
1

I started another thread about 4.3 being “sluggish” and since then I’ve installed on a second computer. Again, it’s sluggish, and the more disturbing thing (because it affects my ability to work) is that I am much more limited in the number of virtual machines I have open.

I usually have 20 or so qubes open, now after about 8, if I try to open another, I am told I can’t open it because there’s not enough RAM.

This is on the same laptop that handled 20 qubes at one time with no errors, same RAM, etc. So this might account for why my installation is more sluggish.

Does anyone know what information I could gather to provide a useful bug report on this topic?

Thank you.

2

My answer will not really help you but for the moment you could try to use GitHub - mirage/qubes-mirage-firewall: A Mirage firewall VM for QubesOS to gain in memory and performance

2 Likes
3

I suspect it’s just the march of progress. Linux distributions are professionally engineered and overall pretty tight, but as software becomes more capable and featureful it needs more resources. A small increase in memory need, compounded over 20 qubes, is maybe no longer a small increase.

That said, you might try looking into zram (pretty easy) or converting some of your qubes to minimal templates (harder). Prioritize the “always on” qubes. The mirage firewall that @dkzkz linked is an easy win too.

2 Likes
4

My bet would be, that you have disabled memory management for some qubes or have set the initial=max memory for them.

Since I was memory-curious i made this widget to show memory usage.

To test your statement i started off with :
9 / 30 / 32

Starting a 20GB init=max qube without balancing fails due to:

Same with 18G init=max :
27 / 31 / 48

With 10G init and 32G max + balancing :
19 / 31 / 61

Try it for yourself - worst case, @Euwiiwueir is right and your system really uses too much ram.

1 Like
5

Thanks. I have no “always on” qubes at all, and I use minimal templates for almost everything, certainly for all of my service qubes.

1 Like
6

All of the qubes were imported from 4.2, with settings that allowed me to have 20+ qubes open with no problems. I can’t remember ever disabling memory management in all my years using Ques, or setting init=max. I’m pretty sure they are all 400 initial / 4000 max, as per the defaults.

I’ll try your tool but can anyone say what is a secure way to copy it to dom0?

7

So I just learned that 4.3 is only recognizing 16/32GB. So that could explain this problem. (It would not explain why 4.3 feels generally sluggish, as that happens from the moment I boot.)

So I’ve opened a thread in user support asking about this. I do think that this laptop was rated for 16GB before 8GB sticks came onto market, but I’ve used it happily with 32GB for years, up until I upgraded to 4.3.

8

qvm-run --pass-io app-browser 'cat /home/user/Downloads/script.sh' > script.sh

9

Hello, the memory reporting in my inplace upgrade 4.3.0 reflects 32643MB of my 32 GB in global settings. Something else must be involved other than just the version change. I know that doesn’t help much but it might redirect the focus towards the root of the memory reporting problem.

Maybe verify the bios is actually reporting 32GB and not 16 in case some memory is going south. Maybe some memory diags? Then maybe search further for fedora 41 memory issues. I think you may be correct about fedora after I searched more about performance and memory. The newer version may not like your hardware combination like the earlier versions. Perhaps some of their drivers were tweaked, IDK? Perhaps the memory could be tested by swapping memory with a friend to see if you get the same results? I have Intel cpu and video and haven’t an issue with memory reporting or performance. Am currently actively running 18 vms in addition to dom0 with no issue. The hardware and OS may be the difference in play here??