Error starting domain: Storage volume not found: no storage vol with matching name 'Kicksecure.qcow2'
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper
callback(asyncjob, *args, **kwargs)
~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 107, in tmpcb
callback(*args, **kwargs)
~~~~~~~~^^^^^^^^^^^^^^^^^
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1384, in startup
self._backend.create()
~~~~~~~~~~~~~~~~~~~~^^
File "/usr/lib/python3/dist-packages/libvirt.py", line 1390, in create
raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: Storage volume not found: no storage vol with matching name 'Kicksecure.qcow2'
Either .xml define the path, or we change libvirt to the user level location, because by default libvirt dont expect session to be used.
Please choose which way you want to go so i can edit the wiki instructions or the .xml based on it, either:
Path comes with .xml (remove default).
Edit libvirt to make default point to /home/user/.local/share/libvirt/images instead of /var/lib/libvirt/images/.
default points to /home/user/.local/share/libvirt/images in qemu://session on a fresh installation for me. I did not had to take another step to define the storage pool to that directory
Same for Debian. No directory needs to be created. It is there by default when adding a QEMU user session connection as noted before. I agree that the system connection instructions should be moved to Dev/Deprecated instead of trashed completely.
Only the dgram socket feature seems to function; as in it creates the socket at the designated path, while stream sockets donât go that far. Connectivity on the GW is still effd however with no error message to give a clue on whatâs wrong.
Interfaces are listed at the usual ip addresses under ifconfig though
This step: mkdir -p ~/.local/share/libvirt/images
should be listed under troubleshooting or known bugs since I donât encounter it on a vanilla Debian host
Same for this entire section: âTell libvirt to stop trying to adjust resources limits and force libvirt to skip itâ
For the Whonix page
Encrypted Containers section should show the entire xml stanza for the storage section since it has now been changed to use storage pools rather than absolte paths. For a user to correctly use paths again, there must be a full correct example for it as currently used.
There should be no âsudo virshâ anywhere on the page since it is possible to use libvirt rootless so please change it to just virsh
Which command / program is supposed to create folder ~/.local/share/libvirt/images? In other words, pls delete the folder, re-run the KVM installation commands, in between keep checking the folder exists yet.
For the fun of it, I used AI to create a CI script to find that out. Finding: virsh pool-build creates the folder.
Virt Manager might create the folder but that doesnât seem reliable. Also instructions ârun Virt Manager, then go back to terminalâ sounds weird. There shouldnât need to be any dependency on Virt Manager anyhow.
According to AI research, there is also a different way without mkdir and without cp / mv.
virsh -c qemu:///session pool-create-as default dir --target "$HOME/.local/share/libvirt/images" --build
Tested Whonix 18.2.1.0, working good. With the same issue mentioned above about the path, so i added the patch to fix it and mirrored that to the wiki:
Doesnt work for default/fresh installation of KS, Ubuntu.. i can test more but thats not the point, hulahoop seems to have old distro (keeps upgrading) and already pre-configured KVM before and forgot or so. So my method gonna work for fresh OSs (debian based) while current method doesnt work out of the box.
Yes. You no longer need dnsmasq and can safely disable its process from starting provided that you disable the âdefaultâ network that comes with qemu:///system as I had posted in another thread. However passt itself has native dns support and runs in a network namespace. I havenât seen it open raw ports last I checked. Feel free to test and confirm.
You can look at the passt manual here to further customize dns/dhcp usage:
-D, --dns addr
Instruct the guest (via DHCP, DHVPv6 or NDP) to use addr (IPv4 or IPv6) as a nameserver, as configured (see options --no-dhcp-dns, --dhcp-dns) instead of reading addresses from /etc/resolv.conf. This option can be specified multiple times. Specifying -D none disables usage of DNS addresses altogether. Unlike addresses from /etc/resolv.conf, addr is given to the guest without remapping. For example --dns 127.0.0.1 will instruct the guest to use itself as nameserver, not the host.