I think throwing out dynamic image numbers things would be much simpler and would avert alot of problems. No need to patch for a
generic image name, static but different domain names hardcoded into xml dpending on what they are kvm, qemu etc.
Lets use the scheme: Whonix_Gateway.qcow2 instead
and
whonix_gateway_kvm.xml whonix_gateway_qemu-x86-64.xml
What caused us to panic and abandon the import script was that we tried to include many things in it that are out of scope. This mission creep made it seem like a nightmare to do this in a quick and easy fashion. I admit typing in a list of commands to get the thing up and running is a chore. New users might panic.
I propose a new import script design that is based on the Keep It Simple design:
What it is and its purpose:
- Scripts purpose is to provide an automated way to register a vm by feeding virsh the import commands and telling it which xml to apply that data from, no matter what the xml file name is as long as its in the same directory as the script. The xmls are run separately and one at a time. By putting each containment type into a different xml that makes things much easier.
2.We are only concerned with a bear minimum subset of virsh commands to do the import process
- It will NOT attempt to change or patch anything into the xml according to alternative config, the users can do this for themselves by directly editing the XML. However there is one exception to the patching:
One Exception: Script obtains the absolute path of the directory it resides in (and hence the image file) and patches that in the xml for the storage path parameter. The image file name is spared. Should the user wish to rename the image from its generic name, they would need to modify the xml and change it so that virsh can read this info correctly.
- 2 scripts one for each tar needed but can essentially be the same.
The start of the script would display the security warning - but this is excluded in the future should someone want to use it as a generic import tool.
A second warning before we start the import would be to say: please remove any machine using the same name from libvirt. This can be done by using virt-manager or virsh using the undefine command.
Note: Deleting the storage associated with the machines being removed is not necessary. You can configure them with a different name and re-run this script to import them later.
Benefits to this approach over past ones:
-No need to path the hell out of one xml to run it as a different configuration
-No need for an export function as the images and xmls are already in their original folder which makes this setup portable. Moving it to a new machine, a user would simply run the script that defines the machine there.
-No copying or moving of anything.
-Solves the overwrting and dupe probem as new version reside in their own newly unzipped directories and more than one xml can be told to use the same disk img.
-users avoid dupe problem with network as they simply don’t define its script if they already done so in the past.
+++++++++++++++++++++++
On shared folders:
Feel free to add the automouting code inside Whonix for a specific directory inside. That way should any user enable it from outside it should work in a convenient fashion. We must tell users in the readme the tag name however that they would use.
While KVM folder sharing is developed with security in mind and is very robust, I think that shipping the Whonix configuration to allow it by default is a bad idea. We don’t want an adversary counting on that to be the way things are on every Whonix install out of the box.