ALSchwalm
commented
3 years ago A brief list of possible commands. Hopefully the expected behavior is relatively obvious:
transient pull generic/alpine38:v3.0.2
transient create my-vm-name generic/alpine38:v3.0.2 --ssh --copy-in-before /foo:/bar -- -m 1G -enable-kvm
transient start my-vm-name
transient run generic/alpine38:v3.0.2 --name <optional name> --ssh -- -m 1G
transient ps
transient ps -a
transient disk ls
transient disk rm
transient disk mount
transient disk build
transient ssh
transient scp
transient rsync
transient revert <vm name>
transient stop <vm name>
transient commit my-vm-name new-disk-name (I guess this fails if you have multiple disks?)
Transient was originally designed to provide an interface that really just added a little bit to the QEMU commandline and did some ssh setup. Over time it kind of grew to handling a lot more setup, so I'm thinking it may make sense to change the UI to reflect this new setup. In particular, originally transient didn't have any knowledge of other transient instances. There was no way to list running vms or ssh to existing vms. Now, these things are possible, so the 'name' of a vm in transient is more meaningful.
Additionally, I think having the option to have an explicit 'create' step for a vm that would allow you to start/stop the machine multiple times could be useful. This is already slightly possible via the config file support in transient (e.g., you could have a dir with a set of config files representing each VM you want use, but this isn't something anyone does in practice, I expect).
With that said, I'd imagine this create step would look something like this:
So we have an explicit name field which is required when using a 'create' command, and we use normal long opts instead of trying to emulate the QEMU single minus opt thing. Note that this command would not start the VM, just create a directory in the FRONTEND with the given name and with a config file generated from the flags you specified.
The VM can then be started via:
Note that only VMs defined with the current FRONTEND would be available to the start command. Of course, it would still be possible to create and start a VM in a single command as we do now:
In this case, the name is optional. If provided, a 'create' step will happen and the VM definition will persist after shutdown. Otherwise, the VM will be completely ephemeral.
I'm just playing around with this idea right now. My main concern is that it would add a bit more file-state to transient, which it was a design goal to avoid. In particular, I really want to avoid any situation where the state reported by transient is in some way not 'in sync' with the true state of the system. These kinds of issues are common with libvirt, in my experience and are very frustrating.