For an openly developed, FOSS GPL licensed hypervisor, it is recommended you use KVM [Kernel Virtual Machine] that comes with the GNU/Linux OS. KVM combined with the VirtualMachineManager front-end should provide a familiar and intuitive, easy to use GUI.

For a detailed view on its security merits read the report issued by an independent security auditing firm.

Recently, the VirtualBox developer team have taken the decision to switch out the BIOS in their hypervisor with one that requires compilation by a toolchain that does not meet the definition of Free Software as per the guidelines of the Free Software Foundation. This move has been deemed problematic for free and open source software projects like Debian, on which Whonix is based.

The issues of the Open Watcom License are explained in thread on the Debian Mailinglist and can be summarized as issues surrounding the contradictory language of the license, the assertion of patents against software that relies on it and the placing of certain restrictions on uses of the software.

For those who care about running Free Software and appreciate its ethical views, it is recommended that you avoid running VirtualBox, for that reason alone if nothing else. Read more about why you should avoid non free software.

Besides this licensing issue which may or may not be of concern to users, a more tangible reason can be the security practices of Oracle, the corporation behind VirtualBox. Recent events and news (see Snowden leaks) have shown the urgent need for increased transparency and trust in the digital world. Oracle is infamous for their lack of transparency in disclosing security bugs details and for discouraging public full disclosure by third parties. Security through obscurity is the operandi at Oracle.

Not going public with a vulnerability and its details only leads to laziness and complacency on part of the company that fields the affected products. A 0day reported privately to Oracle in 2008 by an independent security researcher has unfixed as of 2012 when this post was written.

Furthermore VirtualBox contains significant functionality that is only available as a proprietary extension, such as USB and PCI passthrough and RDP connectivity. Seeing Oracle's unfriendly track record with the free software community in the past; examples include OpenSolaris and OpenOffice, it would not be a stretch to imagine them charging money for the closed up features at some point in the future or simply abandoning the project if they cannot monetize it to their liking.

If you are using a Linux distribution, that is not documented above, click on expand on the right.

You need to have qemu-kvm and libvirt-bin. If you want to use a graphical user interface, which you most likely want, you also need virt-manager. Likely the required software can be installed using your usual distribution's package manager.

If you get one of the following errors while later using virsh define.

The KVM qxl package: xserver-xorg-video-qxl suffers from performance bugs caused by the Xorg surfaces feature. You will notice the graphics lagging even during mundane tasks such as scrolling down a webpage. This has been reported extensively and fixed upstream in testing. Until testing becomes stable, a workaround provided by a Whonix package is available.[2][3]

In the guest install the fix:

sudo apt-get install qxl-xorg-enhance

Whonix 13 users: To get rid of the Whonixcheck PVClock warning, upgrade the packages in the VM. This assumes you have enabled the Whonix stable repo:

In order to be able to manage virtual machines as regular (non-root) user, you need to add that user to the libvirt and the kvm group. Assuming the simple use case, that you wish to use KVM with the user you are currently logged in, and assuming you are using Debian, simply use the following command. (On Ubuntu the group names vary and is called libvirtd instead).

It is highly recommended you read and apply the steps outlined here. By applying a known and tested configuration, you will be better off in convenience and security.

Make sure you use the qcow2 images that are provided by the Whonix project instead of rolling your own. [7] They contain important performance optimizations. [8] (Unless you created them from source. [9])

Modifying a machine's XML file gives more fine grained control over its settings than what is exposed through the virt-manager GUI. Unless you know what you are doing, editing configuration defaults is neither recommended nor necessary.

The supplied XML files serve as a description for libvirt, that tell it what properties a Whonix machine and networking it should have.

Legacy instructions: applies up to Whonix 13

1. First we will start with Whonix-Gateway:

virsh -c qemu:///system define Whonix-Gateway*.xml

2. Followed by the Whonix isolated internal network (XML also in the same folder as Whonix Gateway):

virsh -c qemu:///system net-define Whonix_network*.xml

If the definition of the Whonix internal network fails because the network bridge "virbr1" already exists, edit the Whonix_network*.xml file and change the name to one that doesnt exist, e.g. "virbr2" (you can list all existing bridge adapters with "sudo brctl show").

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

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

3. Lastly the Whonix-Workstation:

virsh -c qemu:///system define Whonix-Workstation*.xml

New Settings for Whonix 14+

1. Add and activate the virtual networks (settings files also in the same folder as Whonix Gateway). If the definition of the Whonix internal network fails because the virtual bridge "virbr2" already exists, edit the internal_network*.xml file and change the name to one that doesnt exist, e.g. "virbr3" (you can list all existing bridge adapters with "sudo brctl show"):

To interact with KVM disk images use qemu-img. It can resize, convert virtual disks to other formats and more. Its not necessary nor recommended to change the official images so proceed only if you know what you are doing.

Whonix disk images are sparse files, meaning they expand when filled rather than allocating their entire size, 100GB outright. These are known as sparse files and need special commands when copying them to ensure they don't lose this property, leading them to occupy all the actual space. We are copying to a privileged location in the system, so we have run with higher privileges (sudo):

After importing Whonix, you are advised to delete the archives (.libvirt.xz files) and the temporarily extracted folders or to move them into a custom location. This is useful to avoid conflicts and confusion should you later download a new version of Whonix.

Reading the latest news is important to stay on top of latest developments. Should security vulnerabilities ever be found in Whonix, any major issues (such as with the updater) happen or should an improved version be released, you should be informed.

For your convenience, there are multiple choices to get news. Choose at your preference.

Whonix Important Blog - Most important stuff only. Security vulnerabilities and new stable versions only. For people with very limited time and interest in Whonix development and news.

Whonix Feature Blog - Includes everything from Whonix Important Blog. Also testers-only and developers versions are announced. Has a relaxed posting policy. Also blog posts about updated articles, new features, future features, development, call for testing, general project thoughts and so on will be published.

It's recommended at least to read Whonix Important Blog if you are in a hurry. Have a look into Whonix Feature Blog if you are generally interested to learn about anonymity/privacy/security related things or to see what's going on with Whonix.

By default, Whonixcheck runs automatically from time to time whenever the user starts up a Whonix-Workstation (commonly called whonix-ws). When run, Whonixcheck will verify that the Whonix system is up-to-date and that everything is in proper working order.

Even though Whonixcheck should run automatically from time to time (i.e. not every time the user starts a Whonix-Workstation), you may want to manually run Whonixcheck just to make sure that everything is in order. To do that, follow the directions below

If you won't get into trouble by letting others learn about Whonix, feel free to follow or like those profiles (with your anonymous account) as a little way to Contribute. You can share this page on: Twitter
|
Facebook
|
Google+.

In this scenario Workstations will not be able to communicate. This is recommended to keep different Tor activity profiles completely separate from each other. To run multiple Whonix-Gateways you need to clone existing machines. These steps assume an existing Whonix install.

1. Create clones of the Gateway and Workstation VMs rolled back to clean snapshots:

In Virtual Machine Manager:

Highlight VM -> Open -> Virtual Machine -> Clone... -> Clone

2. Export Whonix's internal network settings:

sudo virsh net-dumpxml internal > internal2.xml

3. Edit the network configuration to make it unique. Change the name and bridge name. Delete the mac address and uuid parameters. Alternatively, replace the configuration with the example below:

Note that virbr1 is assigned to the external network (NAT NIC), and virbr2 to the internal network (Whonix NIC), therefore, the network name was changed to internal2 and the bridge name to virbr3.

4. Import and start the new network:

virsh -c qemu:///system net-define internal2.xml

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

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

5. Attach the Gateway and Workstation VM NICs to the new network. Its important you pay attention and match internal network interfaces to the newer ones and not switch to a NIC that connects outside. To edit the VM virtual NIC settings:

Note that the network is exclusively internal and does not communicate with the host in any way.

6. Its recommended that you also edit the cloned workstation's configuration and change the pinned CPU's number to a different number (3 or 4) than used by the gateway and primary workstation. Only works if you have a quadcore system.

Microphone input to guests, while a nice feature for VoIP, is dangerous to have on by default. It is good practice to disable the microphone on your host system through sound settings if you are not actively using it.

Its not currently possible to ship a configuration file with the guest microphone input muted. If you need to have the host microphone turned on while denying access to the guest, mute the "virt-manager: record" device that shows up in the host's audio task-bar menu.

Open Whonix's network XML file and change the name attribute to something different than the internal network you are currently running, for example 'Whonix2' 'Whonix3' and so on. The default name used is 'Whonix'.

Libvirt can support a variety of containment mechanisms. Currently supported ones are KVM on the x86_64 platform and QEMU. More configurations could be added at a later date. If you have hardware virtualization extensions, always use the KVM one.

If you want to be able to debug a Linux kernel that’s running as a KVM guest, you need to specify the ‘-s’ parameter for the command line of qemu-kvm. The problem is, there’s no (easy) way to do this when you’re using libvirt and virt-manager to manager your virtual machines, instead of using KVM directly. What you need to do is change the XML configuration of the virtual machine so that the ‘-s’ parameter is passed on to qemu-kvm

virsh edit guestvm

Here, guestvm is the name of the VM that is managed via virt-manager. This will bring up the XML configuration of the VM in your editor. The first line of the XML file should be:

under the <domain> level of the XML. After you save and quit the editor, the new configuration will come into effect. When you start the virtual machine, there will be a local TCP port (1234 by default) that can be used as a remote debugging port from gdb. You can connect to this port by using the command

QCOW2 virtual disk images are the recommended and default storage format for KVM.

LVM or any other storage mechanism must be avoided for security and privacy.

LVM misconfiguration has serious security consequences and exposes the host filesystem to the processes running on the guest. [24]

Because a virtual disk is no longer used, where the low-level view of the storage can be controlled, data created by VMs can easily be recovered and exfiltrated by malicious forensics tools run in a VM at a later time. This is extremely dangerous and can expose all kinds of information originally created in a VM of higher trust level. This leads to deanonymization, past session linking and theft of sensitive information and keys.[25][26] Disabled in cloud tenancy environments.

THP/Hugepages aid rowhammer attacks[27] and memory de-duplication attacks (see KSM below) and so must be disabled for the guest and on the host. As far is what we know Debian hosts do not enable this feature. Disabled in cloud tenancy environments.

SPICE allows accelerated graphics and clipboard sharing. The clipboard is disabled by default for security reasons to prevent accidentally copying a link to a website you visited anonymously to your non-anonymous host browser or vice versa.

KSM is a memory de-deuplication feature that conserves memory by combining identical pages across VM RAM. It is not enabled by default. Enabling this feature is dangerous because it allows cross-VM snooping by a malicious process.[29] It can infer what programs and what pages are being visited outside the VM. [30].Disabled in cloud tenancy environments. This feature can also allow attackers to modify/steal APT keys and source lists of the host. [31][32]

We do not want to port to network manager at this point, because there is no reason besides this issue. For one reason, because ifupdown works well with Whonix for a long time and is well tested. It is unclear if network manager, specifically cli, is ready for prime time yet. What network manager reports is that it does not manage these devices. It's not an error. Just an information. What we would like to do would be hiding that systray item by default. Or suppress that information. Or not starting that systray by default. Because that would cause less confusion. Network manager is installed to make it easier for users setting up VPNs using its graphical user interface.
All attempts so far fixing it have failed. Help required for fixing it.
Long standing known issue.Fix Unmanaged Devices Network Manager

This is a wiki. Want to improve this page? Help welcome, volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.Whonix (g+) is a licensee of the Open Invention Network. Unless otherwise noted above, content of this page is copyrighted and licensed under the same Free (as in speech) license as Whonix itself.