Best we can do is attempt to auto detect this. Like the start-tor-browser script does. It checks for zenity, kdialog, gxmessage, xmessage and opportunistically uses one of them. There may be very well be situations were none of them is installed by default.
Yes. Just notifying them should be enough as its impossible to know what they want to do to deal with this.
Well, not impossible, but needs some time to implement to ask the user on how to proceed.
I believe that 2 scripts, one for each image is a better modular design solution.
That's it for now.
But the setting up information for the isolated whonix_network.xml is to be included and triggered from the whonix gateway script.
Easy and done. The import script checks if whonix_network.xml in it's own folder, if no, it's skipped.
If the script detects an already existing virtual network from a past install, it should exit silently.
You mean skip adding the virtual network then?
This is not implemented yet, but should be.
How can the script check, if the virtual network already exists?
Concerning the virtual network there is a problem :
I believe its very important to put a security warning at the beginning of the process in the script to warn people to shutdown any currently running Whonix vms as they will be using this same internal network.
An adversary who has compromised the older running whonix workstation could attempt to attack the newly added vms that are programmed to used this same internal network.
We have an info text when importing VBox VMs.
Could you write such a text for KVM?
Adding it to the script once written, adding it to the script including a --skip-info switch would be trivial.
Yes libvirt auto-detects and interacts with vms that belong to all supported hypervisors. In this situation its best to change the name then to the other format. With that said I think the suggested renaming mechanism to accomodate hypervisor type and architecture version (just the naming and not the actual changes for the architecture) is important in the case of libvirt to allow people to tell machines apart. For example they may already have a kvm machine and also want to install the qemu version of the same number. Wihtout implementing this, the kvm machine would be wrongly detected as a duplicate of the different qemu machine that a user wants to introduce. Its much more helpful considering the sheer amount of containment types libvirt supports.
I hope you're right. Was quite some work, but it's now implemented in the repo (still untested due to open questions raised above).
We're now using for image.
We're now using for domain name.
Maybe add extension (.qcow2) to domain name as well? No?
I foresee one issue. Someone asking in the forum "In past I could only use qemu, but now I got a new computer and want to use kvm. I got an image named Whonix-Gateway_8.3_qemu.qcow2. Why is qemu hardcoded? WTF? Can't I just use it in kvm? Perhaps we got to live with that.