In the Whonix wiki there is a topic entitled ‘Boot your existing, installed Debian Host into Live Mode with GRUB LIVE’. That would be a good state of affairs. You run your Whonix, but no trace of it, not even in the host, would be detectable. Problem is that running my host (Buster) live, prevents running Whonix. Start of Gateway dies with the message that there is no disk space available. When I check via Nautilus I see in effect I have only 4 Gb left. So installing the Gateway.qcow2 file does not succeed (as logged in syslog by module OM). I do have a relatively small system, a 120 Gb sdd and 8 Gb ram. I guess the 4 Gb is the Gb that are left free in ram, right?
If so, what is the point in running the host live, as it is my intention to start Whonix? Or how much ram would I need to do so: live host + Whonix (live or not live, if that even matters…)?
I only tested it with a Debian buster host, a Kicksecure host, Whonix VirtualBox and 32 GB RAM.
Might not be possible to run with 8 GB RAM indeed.
Reference:
@Patrick: just for my understanding, if you run a live host and you go with Nautilus to any place and click for properties and you see how much free space is on your disk, what does it say? 32 - (approx)4 = 28 Gb?
Could you test this please? @onion_knight
After installing Whonix host operating system - #189 by Patrick and grub-live package.
If not a too personal privacy intrusive a question, how much host RAM can you test this with? 4 GB, 8 GB, 16 GB, 32 GB? Does booting into live mode work and are VMs still startable? Multiple VMs?
Is there a difference Whonix-Host ISO Live vs Whonix-Host installed Live?
Ok.
I can go up to 16GB.
I’ve got the same problem. Also using a Kicksecure host.
I even increased the RAM overlay partition capacity by setting it to overlay-size=36g on a machine with 48GiB and still got the same error.
One of the things I noticed is that, after lanunching the VM, the entire overlay partition usage (df -h) starts growing until it gets completely full.
I believe the actual problem is that the live copy-on-write mechanism doesn’t respect sparse files and ends up filling the entire RAM partition by trying to fit the whole qcow2’s +100GiB in it.
Maybe this would help.
chmod --verbose --recursive ugo-w "/var/lib/libvirt/images/Whonix-Gateway.qcow2"
And.
chmod --verbose --recursive ugo-w "/var/lib/libvirt/images/Whonix-Workstation.qcow2"
References:
Thanks @Patrick !
That’s a brilliant approach: OverlayFS doesn’t have Copy-On-Write issues when it just doesn’t need to write!
The chmod -w didn’t work on its own, though. As mentioned in your references, I had to edit the libvirt XML settings as well.
To all those who come after me, here’s my humble contribution:
Quick and dirty solution (see answer below)
In normal boot mode run the following:
sudo virt-xml Whonix-Gateway --edit --disk readonly=on
sudo virt-xml Whonix-Workstation --edit --disk readonly=on
sudo chmod --verbose --recursive ugo-w "/var/lib/libvirt/images/Whonix-Gateway.qcow2"
sudo chmod --verbose --recursive ugo-w "/var/lib/libvirt/images/Whonix-Workstation.qcow2"
Then, make sure to run both host and guests in live boot mode.
There’s more.
And instead of re-inventing this, look at package whonix-libvirt. Look at each individual file. Don’t be daunted. Deduce what it’s doing from the file name and/or contents of the file. Those related to live mode will say so.
whonix-libvirt is planned to be part of Whonix-Host Operating System Live ISO, Whonix-Host Installer which isn’t done at time of writing. whonix-libvirt would show a warning about not yet finished Whonix-Host which wouldn’t apply.
It might be possible to use whonix-libvirt with Whonix ™ Packages for Debian Hosts and Whonix ™ Host Enhancements. But I don’t maintain Whonix ™ for KVM.
This is a Whonix KVM specific issue.
Consider Live Mode for Kicksecure ™ - Kicksecure unsupported for Whonix ™ for KVM until/if supported by Whonix KVM maintainer through documentation or package.
See: Undocumented, Untested or Unsupported Features
//cc @HulaHoop
Aside from Whonix’s particular use case I must add that the idea of a hypervisor in a live USB/SD card is very attractive to security-minded sysadmins: it provides better isolation than containers and, by using KVM’s shared filesystems backed by live-boot persistence media in chosen dirs, one can achieve something similar to Alpine Linux’s Data Disk Mode but having access to the entire Debian ecosystem. Also, if the guest fits in RAM then any OS can take advantage of it. Maybe Kicksecure could get an edge from this…
(Rack-mounted servers usually have internal USB and SD card slots. Due to their lack of redundancy and their short write lifespans, installing bootable hypervisors and using them in RW mode has led to disaster in some minor cloud providers. Persistence should be set up on the RAID array in this particular use-case)