Whonix Wiki Download Docs News Support Tips Issues Contribute DONATE

[Help Welcome] KVM Development - staying the course

In the wiki history link https://www.whonix.org/w/index.php?title=KVM&action=history

There every wiki version can be compared with every wiki version and it will show exactly what was changed (added text, removed text, edited text) as well as show which wiki account made the edit if any. Otherwise

Example wiki diff (these are easily accessible from the wiki history):

On that link…

Take special note to:

Top left, base revision to compare:

Revision as of 22:04, 9 March 2022 (edit)

Edit by - localhost (because the server doesn’t store IPs). = anonymous edit, no wiki account.

Top right, target revision to compare:

Revision as of 07:47, 19 April 2022 (edit) (undo) HulaHoop

Contains your user name.

As for the first malicious wiki edit:


Left top side, previous version by (no wiki account, anonymous). (That’s just the last edit that was accepted. Not necessarily an issue.)

Right top side, changed version also by

So 100% confirmed it was a anonymous edit.

1 Like

Sometimes I make edits when I’m too lazy to sign in, that’s why I assumed that’s what happened here. Thought it was coming from a trusted source.There’s no excuse for this lapse though and it’s the first time I encounter this.

Keep or discard? Can this have security consequences?

1 Like

Great that this is resolved now.

I guess the user who posted Initial setup Whonix-Gateway might have added this trying to be helpful.

Discard if not reproducible.

No security issue.

Since the wiki has a chapter:
Why use KVM over VirtualBox?

It begs the question:
Why use KVM over Qubes?
Currently undocumented.

Other related new wiki chapters:

1 Like

Does Whonix KVM require VT-d?

1 Like

No only VT-x. Only hardware passthrough like GPUs woudl need VT-d but this is unrecommneded for security reasons and virtio devices should be used whenever possible if high performance is needed.


I thought for a long time VT-d was a required feature…

In qubes saying:

required for effective isolation of network VMs

Maybe they are talking about Xen design but not the same case in KVM?

Qubes network VM = sys-net, which has a physical device(s) attached (LAN card and/or WiFi).

Added VT-x vs VT-d to wiki:
Difference between revisions of "KVM" - Whonix

invalid argument: could not find capabilities for domaintype=kvm is in the wiki to be documented under troubleshooting probably for ages but never had any content. Could you remove or document please?

Is above older / similar / same as the VT-X issue invalid argument: could not get preferred machine for /usr/bin/qemu-system-x86_64 type=kvm?

For new KVM builds, temporarily, please note this Special Notice.

1 Like

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:

Another ticket to clear up confusion created just now:

1 Like