Not even Xen, this is a Qubes only hard requirement to enforce a design decision.
1 Like
Yes seems like it. Both error messages should be merged under a common heading IMHO
1 Like
Not a hard requirement, not enforced. As correctly quoted…
…“required for effective isolation of network VMs”. Hardware without IOMMU are still reported to run Qubes on the same website but these then don’t have “effective isolation of network VMs”.
Well, then if not having IOMMU, then don’t use Qubes because it then doesn’t have “effective isolation of network VMs”? No, that would also be wrong. No operating system would provide “effective isolation of network VMs” without IOMMU. So no Qubes specific disadvantage here either.
So yeah. Computer security. Complicated. Even a short and correct statement actually describing a feature/advantage (“with IOMMU you get effective isolation of network VMs”) with “required for effective isolation of network VMs” can be misunderstood in two negative ways which are false.
Please do as you see fit.
If the older one doesn’t come up anymore, it could even be completely removed.
If users using older systems still run into it, might be useful to keep the error message inside the text.
I stand corrected though in my defense, the last time I checked years ago when 4.X debuted, they implied that they won’t make exceptions for Vt-d-less hardware and reading the hardware reqs seems to imply this by listing this feature as a min req.
1 Like
Please kindly subscribe here:
Yes, the minimum system requirements implies this is a hard requirement. Created a Qubes documentation bug report for it just now:
1 Like
IOMMU (VT-d) was a soft requirement until Qubes R4.0 but is a hard requirement since Qubes R4.1 as per:
https://github.com/QubesOS/qubes-issues/issues/7581#issuecomment-1160426503
Another ticket to clear up confusion created just now:
1 Like
I think we can go ahead and rip out the qxl dependency in whonix and KS as it is now obsolete and we no longer use the graphics device in question. @Patrick
1 Like
For reference only:
1 Like
1 Like
This change is now in the testers repository.
1 Like
Discussing this in 2 forums at the same time makes it a bit weird to keep everything updated. Best to keep discussions in the original, specialized forum thread only and only post a link here for reference.
1 Like
@HulaHoop
I see you’ve been doing Whonix KVM for a long time, but I also see that the builds have stopped.
- what is the state of the KVM development?
- do you plan to continue development? If so, any ETA?
- how much time do you take per month to maintain KVM?
- what takes most of your time during maintenance?
- what are repetitive but necessary tasks that have to be done and takes a long time?
- anything I didn’t ask you’d like to add?
I don’t know if I can maintain, my experience with KVM is not as broad and my time might also be short, but I like that there is a KVM option alternative for Virtualbox, while Qubes is not an alternative for everybody.
1 Like
Didn’t drop the ball yet, just quite busy for now. If I abdicate my post it will be announced beforehand.
Absolutely.
Stable these days. I look at new features under design and make a list of the changes/features I want to add when the new libvirt version included in stable next comes out.
Troubleshooting support topics takes the most time nowadays. Any help with this is always welcome from other KVM power users.
Builds are the necessary and time intensive task you mention, but they are straight forward. Researching improved options in encryption and security software is also something that benefits Whonix in general and not just KVM which I have done. Looking out for security CVEs in Tor, openssl, apt or KVM are very important as those warrant emergency builds.
2 Likes