[Help Welcome] KVM Development - staying the course


virsh -c qemu:///system net-autostart default
==== AUTHENTICATING FOR org.libvirt.unix.manage ===
System policy prevents management of local virtualized systems

Could you please check all https://www.whonix.org/wiki/KVM if it mentions becoming root or suggests using sudo whenever required?

I don’t see how virsh -c qemu:///system net-autostart default could work without root/sudo since this is a system wide change? It’s on a Kicksecure based host for development purposes. Perhaps that broke pkexec or something and therefore sudo is required?

1 Like

Confirmed. You are right sudo is required for defining and interacting with the virsh net command. Otherwise a regular user cannot even see the networks.

This is even the case in upstream documentation:
I will modify the wiki.

1 Like

Also related: interacting with virt-manager without having to input the root password every time you will have to add the user to the libvirt and kvm groups

That specific message is related to polkit policy that can have a rule added to deal with it:

1 Like


HulaHoop via Whonix Forum:

Also related: interacting with virt-manager without having to input the root password every time you will have to add the user to the libvirt and kvm groups

It was indeed related to forgotten application of addgroups and reboot

1 Like

13 posts were split to a new topic: Whonix Software Signature Verification Documentation Discussion - VirtualBox vs KVM - GPG / signify / codecrypt

Could you review https://www.whonix.org/w/index.php?title=KVM&oldid=59133&diff=cur please?

1 Like

Not sure what we wanted to use comments earlier?

New answer. “Comments in libvir xml files now possible.”

Could you try please if now comments can be persisted?

1 Like

Doesn’t work for me unfortunately. Either not supported in this version of libvirt or it’s non-functional. The metadata tag has been in use fr a long time according tot the libvirt manual, but it is for defining custom app XML schema:

The metadata node can be used by applications to store custom metadata in the form of XML nodes/trees. Applications must use custom namespaces on their XML nodes/trees, with only one top-level element per namespace (if the application needs structure, they should have sub-elements to their namespace element). Since 0.9.10.

Unrelated but interesting - when searching he manual I found there is a new feature for disk BackingStores added which seems to me similar to the concept of Qubes Templates. Theoretically one could have one main disk image that shares common elements of both GW and WS while a second one contains only the diff, saving on image sizedramatically, but probably too complex to implement.

1 Like

A post was merged into an existing topic: Whonix Software Signature Verification Documentation Discussion - VirtualBox vs KVM - GPG / signify / codecrypt


1 Like


1 Like


Due to

which probably won’t get any helpful directions on reddit.

1 Like

Thanks for that. Hard to be everywhere at once to take on more complicated support issues.

1 Like


1 Like

Issue creating shared directory between host and guest reminds me… chmod 777 /home/user/shared isn’t a great. Security issue and usability issue.

As per https://chmod-calculator.com/ 777 allow public (i.e. any linux user account including those not having business there on the system) to read, write, execute files from that folder.

Is there some more canonical way to set up shared folders with KVM?

[1] Under which user is KVM attempting to write to shared folders?

[1] Under which group is KVM attempting to write to shared folders?

Perhaps better to create a folder elsewhere owned by that user [1] and group [2]?

I guess libvirt:kvm?

Then user user on the host should be able to read/write files there since Whonix KVM instructions currently include

  • sudo addgroup "$(whoami)" libvirt
  • sudo addgroup "$(whoami)" kvm


Then permissions to that folder could be hardened.

chmod --recursive **o**-rwx

users who are neither the file’s owner nor members of the file’s group

- remove

rwx - read, write, execute

I.e. remove read, write, execute for others, i.e. no other user account than owner (u) and group (g) can read, write, execute there.

Then perhaps “the ultimate set” of commands could be provided that 100% made sure that all permissions are fine no matter how much the user messed that up.

sudo mkdir -p /shared
sudo chown --recursive libvirt:kvm /shared
sudo chmod --recursive o-rwx /shared
sudo chmod --recursive ug+rw /shared

/shared (violating FHS, maybe the not shown in some file managers) or /mnt/shared?

  • /shared is easier to create and fully control permission wise.
  • /mnt more standard conform but then user might mess up permissions of /mnt folder.

Probably also fixable.

sudo mkdir -p /mnt
sudo chown root:root /mnt
sudo chmod o+r /mnt
sudo chmod o+x /mnt

Untested. Please see if that can be made to work:


I was desperately getting them to work when I tried the currently documented steps. I never had any motive to improve them. Yes the current permissions are non-ideal, but I don’t know if they could harm security in practice.

I hesitate to experiment with my setup because I use it heavily every day and it would be a major PITA if it breaks down. If any user wants to try them out and report it works I would be willing to consider.

Yeah that was my main reason why I kept it in the user home folder. Didn’t want to risk messing something up on a system wide level.

Does Restrict Hardware Information to Root - Testers Wanted! work in Whonix KVM now in Whonix

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]