preface: I’m new to both Linux and Qubes so read my post knowing I’m a lowest common denominator user currently and should be read in such context.
After learning a lot lately from being sucked into this forums topics I’m starting from scratch on my setup and doing more compartmentalizing etc. I’ve been game planning out my Qubes structure. While doing this I wanted to know how many Qubes I would have to work with. I initially thought vCPU would limit this i5-8350 (8 Threads x 4 Cores) x 1 Physical CPU = 32 vCPU. default 2 per cub would be 16 Qubes, which I immediately realized couldn’t be right as there’s more than that by default. That lead me here which answers my question that vCPUs can be created at will and over allocated. Also makes sense that you can create more Qubes than hardware resources as just because you’ve created a Qube doesn’t mean it’s using those resources until you start it up. I am a little confused on how over allocating more vcpus to (running) Qubes than you have works but I can research that outside the context of Qubes.
What I couldn’t find in the forum searching was…
Is there a an actual coded limit in Qubes OS for how many Qube VMs you can create in the manager? Ex. you hit 99 Qubes and it won’t let you create anymore? I was actually kind of surprised I couldn’t find someone who asked that yet.
Is there any software or hardware limits for how many Qubes you can run at once? Obviously performance will keep decreasing as you start more Qubes and of course there’s a limit of what you can run on any device. I’m wondering that if you kept opening Qube VMs would the OS prompt you that no more can be opened/it wont open at all because the hardware resources aren’t available or will it just let you continue to open them until you crash your system or make it so slow it’s unusable?
if the answer to question 2 is that you can open any many as you want and performance will just continue to decline is there anyway to determine a guesstimate of how many your machine can run at the same time that is optimal for the resources available or is there just to many variable like whats is going to be running in the qube etc. so it’s trial and error.
The reason these answers are important to me is that I have very specific workflows I’m comfortable with after years of using them (multitude of different sites/programs like distributions, OEM portals, crm, etc. I pull from constantly throughout a day) so I’m building my Qube structure to match and it’s not all suitable to use under 1 single work Qube. It would be inconvenient to have to shutdown and start portions of that workflow multiple times a day if it’s over compartmentalized effecting performance. If I can understand better these limitations I hope i can avoid having to consolidate Qubes many times in a trial and error effort to have all the things I want up with the most compartmentalization that is reasonable.
No, you have 8 threads, which is a bit less than 8 vCPU.
Your CPU has 4 cores, all featuring hyper-threading allowing them to run 2 operation at the same time instead of one, under certain conditions. By default, hyper threading is disabled in Qubes OS because it leads to security issues as it’s been proven that it’s possible to leak data when SMT (the real name for the hyper threading technology) is being used.
It’s possible to enable SMT again if you really want to.
memory will limit you. You can over provision the CPU by running 12 qubes with 2 vCPU each on a 4 cores system, it’s fine as long as they idle, but they will all use some reserved memory.
It depends on what you do, if you use a web browser, you will certainly need 3 or 4 vCPU to be good, if you only have 4 cores at all, the more you keep the qubes running, the less you will have for the “big” usage.
There are no rules for allocating resources. If the qubes are idle and you don’t need a qube with all the CPUs, that should be fine to over provision. It’s still possible to pause a qube when you don’t need it, so it’s still using the memory but won’t use any CPU at all until you unpause it.
Yes I didn’t take into account Hyper-threading being disabled, I was following the formula found on this page. So if take into account no hyper threading (instead of 2 threads per core 1 thread per core) wouldn’t it be (4 core x 4 thread) x 1CPU = 16vCPU? I’ve seen this formula in a few places so not sure if it’s wrong or I’m not grasping something. Question is AMD multi threading also disabled? If not that seems like pretty big advantage to consider AMD machines. Even if it’s also disabled seems like AMD would still have a sizeable advantage assuming there’s no other major AMD compatibility issues.
I’ll read more into this thanks!
I did not consider using the pause function and is a good idea. Is it possible to write a scrip that if a Qube is minimized it is paused automatically? Seems like a good way to conserve resources while not having to close certain VMs fully.
First, thank you for answering so many of my questions lately so please don’t get frustrated if I push back on this particular answer just to make sure. Example below is from the guide I had linked on understanding vCPUS, the example is based on a Ryzen 2500X, which is a 4 core 8 thread CPU. In his example he uses ALL 8 threads in his formula not threads per core. Taking into account no SMT this cuts it down to 4 threads total on the machine that are usable (1 per cpu core instead of 2 per cpu core). The other guides I’ve seen also use all the threads in the CPU in the calculation not how many threads each core can run. Your calculation is using how many threads a single core can run * the full number of cores so that is why I’m confused.
Windows users:
Open Task Manager by pressing Ctrl+Shift+Esc.
Click the Performance tab and select the CPU section.
Can someone confirm/negate the limit param, as from official stand point it looks like unlimited(?)
At first I thought you’re right, as it sounds very logical to me as well, but:
I remember I’ve seen some post by @unman saying there’s sort of unlimited number you can spin and Xen will try to balance them out.
Meaning: it’s possible to spin unlimited of them, but it may not be efficient.
I understand the reasoning now, because it was called a vCPU that doesn’t mean much, in my opinion.
In the case of hosting companies, they split their CPUs into units and they could say with 12 cores, they can give a quarter of a core and sell it as a vCPU. Then, depending on the CPU you want, on AWS you have choice between nano, small, medium, large etc… this mean the share of a single core will increase will the size (and you also get more cores).
Umm, no.
I have a x230 with (currently) 616 Templates and qubes, which should be
enough for anyone.
Of course, I cant run more than 30 or so at the same time.
I’ve not hit any limit.
that’s good to know, as far as I’m concerned that equals (it supports as many as you will ever need), I coudlnt imagine most users coming anywhere close to what you have going on.
I can’t tell you what @unman does, but I have 120 qubes on my laptop and even more on my desktop (the laptop is carefully managed via salt and self-built .deb and .rpm packages to be a subset of the desktop). Not as hard-core as unman, but certainly a lot more qubes than most people have. So my answer might be informative (though I too would love to read unman’s answer).
I back up only a handful of qubes. Why? Because only dom0, the few AppVMs I have (with persistent user data on them), and my Windows VM cannot be recreated at will in an automated fashion. Most of my data lives on a NAS, and it gets backed up pretty thoroughly. I never bother backing up templates (other than Windows); those can all be auto-generated.
Source? obviously that’s more than anyone would need in the context I made the topic but it would be cool if we did have the official answer on the limit confirmed.
I agree that sounds a bit weird, but I left out a key part of the description because I was focused on why they don’t have to be backed up.
In essence, most of my AppVMs are actually disposables (mostly named disposables); they do perfectly ordinary things, it’s just that they mount offline storage, and that’s where the persistent data is. Not part of the Qube itself, but accessed by it. Others are used for browsing the internet, etc.
I joked one time about how you can win the prize for dumbest person on earth by doing backups to a disposable, but I was laughing as I did so, because that’s actually what I do! It’s not an idiot move in this case because the disposable has mounted offline storage, and that’s where the backup goes.
Oh, and I forgot. The one and only template I do have to back up is the one for my Windows 7 virtual machine; that particular template I had to very painstakingly set up “manually.”
