KVM Networking Broken

KVM
1

I installed Whonix-Gateway on a new installation of KVM (on Debian wheezy) on which I already had created a Debian VM that was working without any problems. I’m using the graphical manager with terminal sessions when necessary and this is my first time using KVM.

For the installation of the Whonix-Gateway VM I followed the instructions at: Whonix ™ for KVM

Now both VMs (the existing VM and the new Whonix-Gateway) fail to start and instead give the following error:

Error starting domain: Requested operation is not valid: network 'default' is not active

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 66, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1114, in startup
    self._backend.create()
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 866, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: Requested operation is not valid: network 'default' is not active

Under preferences, virtual networks, there are two entries: “default” and “Whonix.” When I select “Whonix” its properties say, “unknown data type.”

Can anyone suggest a way to proceed?

2

According to the error message the “default” NAT network that’s setup in KVM by default is switched off. Nothing to do with Whonix directly. Please switch it on, using the the virtual machine manager GUI and try again.

3

Hi HulaHoop,

yes, I worked that out eventually and I did indeed got past that error by turning default on at the command line.

However, now I have a new error as well as an old one:

I totally reinstalled Debian wheezy, to have a known starting point. I then installed KVM using the exact steps listed at Whonix ™ for KVM including checking the versions of the installed KVM packages.

I then took an image backup of the computer to be able to return to if I should happen to trash the setup.

I also noticed that the filenames of the qcow2 files in the xml files are incorrect. they are something like Whonix-gateway.qcow2 while the actual files are something like Whonix-Gateway-9.3 so I amended those entries. I hadn’t been looking at the xml files because editing them is listed as an optional step.

I then went through the import steps (after turning on default) and, when I ran the gateway vm from virt-manager, I received the following error:

Error starting domain: internal error hugetlbfs filesystem is not mounted

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 45, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 66, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/domain.py”, line 1114, in startup
self._backend.create()
File “/usr/lib/python2.7/dist-packages/libvirt.py”, line 620, in create
if ret == -1: raise libvirtError (‘virDomainCreate() failed’, dom=self)
libvirtError: internal error hugetlbfs filesystem is not mounted

I note also that, in virt-manager, the virtual network “Whonix” has on its properties pane: “Error selecting network: Unsupported data type: <type ‘NoneType’>” which is the same error as previously mentioned (but after I have restored this computer from the image backup).

By the way, the way I have been putting the files in the Images directory is by copying the xz files into that directory and then running tar -xvf on them there. That should preserve their sparseness. Of course, I also adjusted the paths appropriately in the import commands. I had no errors when running those import commands.

I would appreciate any input on this!

4
I then took an image backup of the computer to be able to return to if I should happen to trash the setup.

Good.

I also noticed that the filenames of the qcow2 files in the xml files are incorrect. they are something like Whonix-gateway.qcow2 while the actual files are something like Whonix-Gateway-9.3 so I amended those entries. I hadn't been looking at the xml files because editing them is listed as an optional step.

The xml filename shouldn’t matter what does is the image name and filepath specified inside in the settings.

The error message you report is very similar to something another user reported a week ago. I suspect its a bug in the package. Can you please install the KVM version in wheezy-backports and report back if it works?

5

“The xml filename shouldn’t matter what does is the image name and filepath specified inside in the settings.”

That’s what I was talking about: the file name INSIDE the xml, not the name OF the xml file. It surely does matter, since it is indicating a file by name.

Unfortunately, as I said, changing it to the correct value doesn’t eliminate the error.

I have been using wheezy-backports, except one time when I forgot to (but I got the same errors on that occasion). The package versions are at or later than the versions in the Whonix KVM setup instructions, just like they say. These are the versions from the latest attempt:

libvirt-bin 1.2.4-1~bpo70+1.1
qemu-kvm 2.1+dfsg-5~bpo70+1
virt-manager 0.9.1-4

6

ok. Lets try something first:

remove the machines from KVM. Edit the xml for both gw and ws to remove the tags and the hugepagetables setting between them. After that rein-import and tell me if it works

If that doesn’t solve it, try the KVM version from the testing repos.

7

But be careful, have backups. Speaking by experience, mixing up stable/testing can lead to difficult to resolve unrelated issues.

8

Hulahoop and Patrick,

Thanks for the tips!

I’ll try Hulahoop’s debugging method later today. I have now reinstalled everything on a 320GB HDD because I was wondering if the fact that I was previously working with an 80GB disk was to blame, since the image disks are defined as 100GB. The result is that I still get exactly the same error that “hugetlbfs filesystem is not mounted.”

By the way, I confirmed once again that the names of the image files in the xml do need to be changed to reflect the actual names of the image qcow2 files. If I use the xml files as supplied then the error when starting the vm is “Error starting domain: Cannot access storage file ‘/var/lib/libvirt/images/Whonix-Gateway.qcow2’ (as uid:113. gid119): No such file or directory”

EDIT: Also by the way, the host computer is confirmed as VT-x capable. It is a Dell Dimension E520, E6320 cpu, 4GB of RAM. It ran Whonix in Virtualbox, with the host OS as Debian wheezy, without an problem. And that was with the 80GB HDD.

EDIT: Also worth mentioning, on the file-naming issue: Instead of editing the xml files I also tried renaming the qcow2 files to reflect their names in the xml files. Doing that eliminated the “no such file” error, just as editing the xml files does, but I still got the “hugetlbfs filesystem is not mounted” error.

9

I got Whonix working and whonixcheck passes on both gateway and workstation. The only flaw I can see is that the panel (i.e., startmenu and task bar) is missing from the bottom of the screen, seemingly truncated, since I still see notifications but partly truncated. I added a panel at the top of the screen to work around this issue.

To get to this point I had to make the following changes to the xml files. Each change was done after starting the VM and getting an error, and then making a change to the xml files (usually as a result of information found on this forum or in the Whonix FAQs), and deleting and re-importing the VM.

  1. tags removed (along with the lines between each pair of tags):

    memory backing

    pm

    rng

  2. Removed the line about “file transfer enabled”

  3. Changed the sound controller to AC97.

10

Disabling rng isn’t ideal for security.

All related to:

11

I wanted to test Debian jessie compatibility. Just did run into this myself. Used a fully updated Debian jessie. (Inside a VirtualBox VM, but QEMU should still work, no?)

error: Failed to start domain Whonix-Gateway error: Requested operation is not valid: network 'default' is not active

Log:

user@debian:~$ virsh -c qemu:///system destroy Whonix-Gateway
error: Failed to destroy domain Whonix-Gateway
error: Requested operation is not valid: domain is not running

user@debian:~$ virsh -c qemu:///system undefine Whonix-Gateway
Domain Whonix-Gateway has been undefined

user@debian:~$ virsh -c qemu:///system net-destroy Whonix
Network Whonix destroyed

user@debian:~$ virsh -c qemu:///system net-undefine Whonix
Network Whonix has been undefined

user@debian:~$ virsh -c qemu:///system define ~/Downloads/Whonix-Gateway_qemu.xml 
Domain Whonix-Gateway defined from /home/user/Downloads/Whonix-Gateway_qemu.xml

user@debian:~$ virsh -c qemu:///system net-define ~/Downloads/Whonix_network.xml 
Network Whonix defined from /home/user/Downloads/Whonix_network.xml

user@debian:~$ virsh -c qemu:///system net-autostart Whonix
Network Whonix marked as autostarted

user@debian:~$ virsh -c qemu:///system net-start Whonix
Network Whonix started

user@debian:~$ virsh -c qemu:///system start Whonix-Gateway
error: Failed to start domain Whonix-Gateway
error: Requested operation is not valid: network 'default' is not active

user@debian:~$

We need instructions for this in the wiki. Ideally command line instructions for easy copy and paste.

Added to Dev/KVM as blocker:

12

Having two NAT’d networks running recursively will not work trust me. It would have worked if VirtualBox has bridging mode configured. If you run a VirtualBox inside a VirtualBox you will see.

13

Maybe right. Anyhow. It happened for Dennis as well and he wasn’t doing this inside VirtualBox. So this still is a grave usability issue for Debian users that needs documentation.

14

I want to understand more the problem so I can simulate. Is it one that appears only when you do nested virtualization or are you saying that on a Debian host KVM fails out with that error - even when hugepages is removed?

When I ran into the hugepages problem I was getting virbr0 failed errors when in reality it had nothing to do with networking.

15

As per Dennis’s report it’s unrelated to nested virtualization. He didn’t mention nested virtualization. Just a Debian host.

16

Everything works fine when the hugepages option is taken out of the xml before import.

The original “network” error was due to my unfamiliarity with how KVM operates (rtfm) and was resolved by activating the default network manually.

Whonix on one KVM (not Virtualbox) on Debian. Never done nesting of hypervisors.

17

You didn’t know it. I was confused by it as well. So we need to document this so no one else bumps into this.

18

I found the note about it in Debian manual. Strange but seems to affect Debian for some reason:

Fixing this is simple, open up virt-manager and go to "Edit" -> "Host details" -> "Virtual networks" tab. From there you may create a virtual network of your own or attempt to fix the default one. Usually the problem exists where the default network is not started.

https://wiki.debian.org/KVM#Troubleshooting

19

Can you try to figure out the command line equivalent for this please? Would be easier for instructions (copy and paste along with the other commands) and also useful for the unit_test.

20

virsh -c qemu:///system net-autostart default

virsh -c qemu:///system net-start default

Please try those and include them.