That implies that there are two different types of blockers (main blockers and blockers). Seems confusing. Either a blocker or not a blocker. Anyway.
but I need input on that.
But there is a new blocker:
KVM instructions have not been updated yet including new subnet from https://www.whonix.org/forum/index.php/topic,328.0.html. And is there anything else from https://www.whonix.org/forum/index.php/topic,328.0.html that should result in a change of the Dev/KVM or KVM wiki page?
Other things that are solved but still as blockers like the virtio-blk, shared folders etc.
I don't know why virtio-blk is considered a blocker. Please add the reason to the wiki. I don't know the problem with shared folders, please add it to Dev/KVM as well. While I am not considering those as blockers (yet, maybe you explain), since you're taking the lead on KVM support, you're free to move those items to blockers.
For virtio-blk I had edited grub parameters for it to work.
That info comes from a Ubuntu centric page. Does it work in Debian as well? Have you tested that solution already?
This will probably need a permanent fix in the repo to solve.
How could that change look like?
I did some digging on the xml solution we thought of and found out that any iser who hopes to run their machine will need to edit their copy of the configuration file to have their own path to the image file and to mask the cpu to match their own cpu model.
Disk UUID I'm not sure of, does the image have a uniform UUID or does it depend on an arbitrary one assigned to it by each system its used on?
As for KVM disk identifiers, maybe KVM assigns a disk identifier on its own to any image, no idea, you tell me.
As for the uuids (" ls -l /dev/disk/by-uuid"), those aren't fixed in Whonix 8 unfortunately (Whonix 8.1 has a different one than 8.2 and so forth), but those will be fixed in Whonix 9 and above. [Has been implemented to ease verifiable builds.]
Either way, ts clear to me that a click and set model like the ova import feature is not possible on KVM right now unfortunately.
Should we instead stick with adding instructions for simple manual edits to be done to the xml like clock settings, graphics ram and the like, but we rely still on manual steps for the large part.
I still preferred this:
Same in other words: doing it similarly as https://github.com/Whonix/Whonix/blob/Whonix8/build-steps.d/2600_create-vbox-vm does.
Same in easier words:
With VirtualBox, we’re doing it like this…
## Create a new VM.
VBoxManage createvm --name "Whonix-Gateway" --register
## Adjust RAM.
VBoxManage modifyvm "Whonix-Gateway" --memory 768
## Add eth0 and configure as NAT.
VBoxManage modifyvm "Whonix-Gateway" --nic1 nat
I.e. are creating all VM settings using the VBoxManage command line utility. No steps using mice required.
Now, KVM can be used in that way as well. It’s all in the man page / docs. Creating the VM settings would be as simple as copying and pasting these commands. And once we’re there, I am happy to script these commands to automate them.