Bought a mini v2 with PureOS on it (very nice) and installed Qubes 4.0.4 from a Librem supplied USB drive. All good, pureboot works nicely, fine.
(well, most of the time, it has hung twice and I’ve had to restart, but it works okay then).
This was to see me along for some time so I got 64GB RAM, 1 TB of NVMe pro SSD and 2 TB SSD to back it up.
(Qubes can be memory hungry and I wanted it to work faster than my old system.)
Restored a large back up of Qubes 4.0.4 from my old computer, updated and all is mostly well. It all works.
(The old computer was a Think Penguin built core i7 6700K with 32 GB RAM and a 512 GB SSD, around 4 or 5 years old.)
But the mini works a lot more slowly than my old 6700K. About half the speed to start up an app vm.
If I go down the qubes manager menu starting a lot of vms all at once, which the 6700 did without problems, it fails after about 4 with a warning and I have to wait and try again.
The cpu uses - I’ve seen it over 60% whilst the old machine never got to 40% that I ever saw - and I look.
The mini has to be better chip - a 10th gen. over a 6th, right? Should be faster . . ?
So what do people think? Does it make sense to say, ‘I have much more memory and storage so there’s more for the installed os to be spread out in so it takes longer to operate’?
Or; ‘I have twice the memory for commands to wade through?’
Surely not . . ? (I don’t have any idea, I’m not an IT pro).
Or could recovering a large instance of qubes from the original cause the copy to have a lot of bloat?
I’m going to totally re-install on just the 1TB SSD and try again unless anyone has suggestions?
Or do people think I ought to just re-install a clean, basic Qubes and build it up from default rather than recovering it from a back up file?
I don’t want to have to do that because it would take ages. There’re years of added domains, files, sys-VPNs, templates, and fiddling about, etc., etc.
Just a disclaimer that I’m not much of a expert or anything, or IT pro as you say also. Don’t have or ever used a mini v2, or pureboot for that matter.
Well my first instinct without telling you to look at qubes documentation would be to check and adjust xen configuration - confirm iommu, and all virtualization options are enabled and functioning still. For example maybe SMT, vt-x, iommu, etc; was disabled on this cpu, or from bios? TBH SMT(hyperthreading) is probably the most likely candidate of something being disabled and not throwing some sort of error, and leading to increased cpu usage. So also while you are doing that check dom0 cpu/ram allocation and adjust. I don’t know what will automatically change when you try to load a full qubes backup os on to different hardware but I’m will to bet you are going to adjust some things if you havent already.
Newer isn’t always better(especially on linux) for example: Lots of trouble running a AMD/Ryzen platform on Qubes when that hardware was new. Also you might have more ram capacity but what speed was your old ram? Though not sure if it matters much on a intel system but amd systems have a huge impact from ram timings and speed. Was the old system iGPU or stand alone GPU? etc. However the specs of the mini v2 seem good so I’m thinking it might be some specific settings.
Worst case you could reinstall Qubes on the new hardware and backup/restore the VMs. Though I haven’t done anything with qubes backup/restore functions to this date so take that with a grain of salt.
Thanks - good solid suggestions, seems to me.
I don’t think Qubes 4 will load if you don’t have vt-x / vt-d enabled, got a warning once to that effect but I’ll check.
I never thought about the hyperthreading, I’ll look into it as well as your other ideas.
Thanks again,
