[html]
You are welcome to check out the build documentation for next major Whonix version (9) (https://www.whonix.org/wiki/Dev/Build_Documentation/9_full) (which is still in development!). It will be possible to choose between different build targets –virtualbox, –qcow2 (most likely if you’re interested in KVM) and –bare-metal using the whonix_build script.
Check out the script, which is responsible for converting the raw image to a .qcow2 image: https://github.com/Whonix/Whonix/blob/master/build-steps.d/2400_convert-img-to-qcow2
For better performance, we are now using “-o preallocation=metadata” for better performance (as per this blog post: http://www.ilsistemista.net/index.php/virtualization/11-kvm-io-slowness-on-rhel-6.html) and “-o cluster_size=2M” as per qemu-img’s man page. The latter increased the sparse size from 2,5 GB to 2,9 GB (as per test: https://www.whonix.org/wiki/Dev/KVM#Set_cluster_size_512_-_2MB_for_better_performance.3F) but this is a compromise we can make for better performance. This space would most likely be used anyway when the image gets booted.
The build process for building, signing, compressing and uploading .qcow2 images has been streamlined to make maintenance of additional .qcow2 images less time consuming and therefore more maintainable. This is done in the https://github.com/Whonix/whonix-developer-meta-files/blob/master/release/compress_qcow2 script which gets run by release automation script https://github.com/Whonix/whonix-developer-meta-files/blob/master/release/new_release as a standard step.
The bad news is, using Whonix with KVM will likely be more difficult than using Whonix with VirtualBox, because neither KVM nor virt-manager have a feature for importing prepackaged appliances. VirtualBox’s .ova appliance import feature makes redistributing virtual machines so much simpler, because it keeps care of storing all VM settings and image compression during transfer.
Compression of .qcow2 images unfortunately is necessary, otherwise transfer using rsync (uploading) or download using a browser would take very long. (Also as per https://unix.stackexchange.com/questions/120091/how-can-i-speed-up-operations-on-sparse-files-with-tar-gzip-rsync.) This means an extra step for users, they need to uncompressed the tar.gz we’re providing.
Also copying around decompressed .qcow2 images (for backup or replication) isn’t that simple as per forum post https://www.whonix.org/forum/index.php/board,1.0.html. On some systems it may be possible to copy them using the console using cp with the sparse parameter, so it will again be a sparse file. Also decompression using some tools may result in a non-sparse file. We still have to research this better and document best practices on how to end up with sparse files.
We’re happy to welcome HulaHoop (https://www.whonix.org/forum/index.php?action=profile;u=87) back to Whonix KVM development who contributed steps into direction of running Whonix in KVM.
Our current KVM documentation draft can be found here:
There are still blockers, that prevent us from recommending wider use of Whonix in KVM:
And there are other open questions (improving security, performance, etc.) we like to answer:
https://www.whonix.org/wiki/Dev/KVM#Non-Blockers
[/html]
If you are interested to see Whonix in KVM, please consider joining our development efforts!