So, again, what sources?
1 Like
It looks like you want to refute my data?
Then please provide your sources, counter arguments and results of your tests.
I even found information somewhere that the Xen hypervisor provides 108% of the native speed and even more, which surprised me extremely.
But that’s certainly not 70% in Qubes.
1 Like
I don’t doubt your data specifically, but rather, data of that kind in general. There are too many variables to consider to make that comparison valid. To compare Xen and another hypervisor based solely on performance, I would install both on bare metal, start a VM with the same amount of resources, kernel parameters etc. and compare the results of running the same application.
Qubes modifies some things for security hardening and integration into the Qubes system design and therefore relies on Xen, but it is not necessarily a vanilla Xen distribution. Therefore, some of Xen’s promises from 2009 wouldn’t necessarily hold true, either.
Apart from all this, though, I don’t understand your goal. What’s the point of saying that Qubes is slower than $OTHERHYPERVISOR platform when you don’t consider the security model and its demands on resources? This is Qubes’s primary design goal AFAIK.
2 Likes
You see, when I got used to Debian’s staggering speed on bare hardware, as well as the decent speed of VBox, I was confused by the slowness of the Qubes.
Of course, these were subjective impressions, so I started testing speeds.
Of course, I understand that increased security requires overhead, but this I’m still annoyed because I’m used to high speeds even on weak computers.
Therefore, I built a more productive computer for the Qubes, but even its speed in Qubes did not please me.
1 Like
Here is my CPU running geekbench, with SMT enabled, all cores assigned to 1 VM.
As you can see, the score (21047) is what you would expect if it was running bare-metal.
I’m sure the CPU would get a slight higher score if I reran the same test bare-metal, but it would be a few percent, and not close to 30%.
4 Likes
That’s great, I’m happy for your success 
But now I have a new problem.
To increase the startup speed of the Qubes, I bought an new NVMe.
But unfortunately, the old motherboard doesn’t see it 
But that’s another story…
2 Likes
That doesn’t look at all like a result with SMT enabled. SMT should give you a huge speedup compared to no SMT in this particular test and probably get you closer to your result from VirtualBox or even bare metal.
That said, other aspects such as memory bandwidth, disk bandwidth, graphics latency and speed are probably worse on Qubes OS than what can be achieved in other virtualization environments. And you will definitely use a lot more RAM capacity with typical Qubes OS usage.
If you mean booting Qubes OS, in my experience you can’t make it really fast even with a fast disk, but hopefully suspend to memory (sleep) works as a workaround. A fast disk should nevertheless help with booting Qubes OS and especially with starting the qubes. Make sure you update your motherboard’s BIOS/UEFI. Also, assuming it’s a M.2 slot make sure both the motherboard slot and the drive are actually NVMe PCIe and not SATA (M.2 can carry either PCIe or SATA).
1 Like
There is no M2 slot in this old motherboard.
So I bought a PCI-E to M2/NVMe adapter.
In this case, the installation of the Qubes on this NVMe is successful.
However, booting the Qubes is not possible because even the most recent BIOS does not see this disk.
Can GRUB from the install medium see the PCI-E card/NVMe? – or will you have to put the /boot/-files on a drive that BIOS can see?
I see. As far as I know, some motherboards from around that time or older don’t have support for NVMe booting, etc. in their firmware (BIOS or UEFI). I suppose ones for 4th generation Intel Core have UEFI (with compatibility mode), but if it is a true BIOS, then I think it will not support it at all. A UEFI may or may not support it, and it may depend on settings. The fact that you use an adapter may change things too.
By the way, some motherboard UEFI remove EFI boot entries whenever you try to boot with the disk not detected for whatever reason, and then they don’t add it back (or at least not the Qubes OS one) when the disk is detected again.
You should check rEFInd as a workaround for poor motherboard firmware boot managers, but beware that booting rEFInd before Qubes OS is essentially like dual-booting, which carries a risk of full compromise of Qubes OS, so it’s generally not recommended. But I think it is very good at enabling you to boot a lot of things that your motherboard would otherwise not let you boot. The idea is that you boot rEFInd from anything supported (SATA disk/USB/optical drive) and it shows you a nice boot menu that includes anything that rEFInd could detect.
Is it possible to install Qubes in Legacy mode instead of UEFI mode?
Yes. When I installed Qubes OS I got support for both Legacy boot (CSM) and UEFI boot.
Maybe this thread needs to be split into a new one for boot troubleshooting though, especially if you need more specific knowledge.
Edit: Check this page too: UEFI troubleshooting | Qubes OS
Of course, you’re right. I fall silent.