Port virtualbox scripts to VBoxManage CLI #625
Conversation
There was a problem hiding this comment.
Thanks for the work @stevemk14ebr! I need to still test the code locally, but I have added some questions and improvement suggestions already. It is good to see what we can do with VBoxManage and how it allows us to remove the virtualbox dependency. The disadvantage is that it is less flexible, as it does not export everything in the API (for example, it seems it is not possible to access the max number of adapters which would allow us to write simpler code as in the previous version) and that we need to create a subprocess everytime we want to run a command. The new code using VBoxManage also looks longer and more complicated, but we may be able to simplify it a bit.
What about keeping both the version using the virtualbox library and the new one using VBoxManage until we have tested and migrated everything else?
Also, I think we need some documentation in /virtualbox/README.md.
| except subprocess.CalledProcessError as e: | ||
| # exit code is an error | ||
| print(f"Error running VBoxManage command: {e} ({e.stderr})") | ||
| raise Exception(f"Error running VBoxManage command") |
There was a problem hiding this comment.
why is it needed to catch the exception to print and error and re-reise it? I see the same pattern in other functions as well.
There was a problem hiding this comment.
Style choice, this throws a pretty error to the top level main to print out. I can change if you think there's a more pythonic style
| vm_uuid, | ||
| "--ovf10", # Maybe change to ovf20 | ||
| f"--output={filename}", | ||
| "--vsys=0", # we have normal vms with only 1 vsys |
There was a problem hiding this comment.
[nitpick] I needed to check the documentation to understand what this is doing, I think we can improve the comment to clarify why this parameter is needed:
| "--vsys=0", # we have normal vms with only 1 vsys | |
| "--vsys=0", # We need to specify the index of the VM, 0 as we only export 1 VM |
There was a problem hiding this comment.
This took me a bit to figure out actually, it is a necessary parameter, but appears to be almost never used by anyone. There exists a concept of multiple virtual systems in a single VM. We don't ever use this, and a normal VM shouldn't have more than 1 virtual system, but it's a necessary parameter so I have had to include it.
There was a problem hiding this comment.
You can export several VMs in the same appliance. I was just purposing to add more details to the comment to clarify it. 😉
There was a problem hiding this comment.
I may need you to educate me honestly, I don't know more than what I commented about vsys
| session.unlock_machine() | ||
| print(f"Restored '{snapshot_name}' and changed its adapter(s) to host-only") | ||
|
|
||
| vm_uuid = get_vm_uuid(VM_NAME) |
There was a problem hiding this comment.
do we need to get the UUID? It seems like the commands work with the VM_NAME (we may need to enclose the entire name in double quotes to avoid issues with spaces), or am I missing something?
There was a problem hiding this comment.
We could rely on the VM_NAME alone, but I use the UUID so that we can support multiple VMs of the same name and be sure we refer to the same VM consistently for all operations
we can, the vminfo command lists all 8 adapters (the max) and any unset adapters have the value 'none'. The code doesn't need to check the max adapters because it lists all of them, even if they're unset, so we always loop all 8 adapters.
I have no issues with not merging these PRs (I will send more for the other two scripts) until we are ready to drop the |
stevemk14ebr
changed the title
Ports to VBoxManage CLI, identical logic otherwise. Errors handled gracefully for the most part. Output: