Ah, OK. My naming convention is a bit odd perhaps.
Salt scripts run either in the dom0 environment, or some other VM’s environment, so you have to do something in the right environment.
My vmname-create.sls script includes the command to actually create the VM, and it includes qvm-prefs, qvm-features, and qvm-tags calls. These are all executed by dom0 so they belong in that environment. So “create” does a little bit more than just creating the qube. This directly corresponds to the fact that you’d normally issue these commands at the dom0 command line.
“configure” runs in the new VM’s environment and it installs all software on the machine (as well as bringing in config files and so on). The file copies in salt all implicitly assume the mod is going to happen on whatever system the environment specifies, so they go there. (In a bash script it would be qvm-copy-to-vm run from dom0.) But installing software must happen on the target machine, either from the command line or from salt.
As it turns out, most VMs have about the same length of “create” salt files, but there’s a big difference between the types of VMs for configure. TemplateVMs have long configure files, DVM templates ideally have no configure file, though I have a couple of exceptions, the DVMs (when I create a named one) have no configure file, and AppVMs usually have something even if it’s just installing user pref files into the home directory. (For DVM templates I used to do it the same way, but then I found out about /etc/skel…which lives on the template, not the app vm.)
I have a bash script that invokes the create file, then the config file (if any). There’s also a rare case where I might want dom0 to do something after config, so there’s a third file that can run (can’t remember what I called it)…if it is present. The script does all that just based on the template name and a prefix I supply it.
I can run the same script to update the software on a VM. It runs create…which will NOT create the VM because it already exists, but MIGHT change prefs and features if they’re different than they should be–that’s good, just in case something got changed, set it back. Then config runs (if there’s a config file) and that should update software and other files if they need to be, then finally that last file. (Yet another issue I haven’t brought up yet is something that final file addresses…I’ll get to it in due course.)
For templates I even set up the config files to include the “parent” template’s config files (e.g., if I clone deb11a-base to create deb11a-wifi, deb11a-wifi’s config file includes deb11a-base’s config file, so I can update everything on deb11a-wifi with one command instead of having to update deb11a-base then clone it again).
But because of this glitch, my create file for DVM templates has to create the dvmt under the wrong name (e.g., to create firefox-dvmt, I create firefox-dvmt1, set prefs and features, then copy that qube to the right name and delete the one with the wrong name–so that at the end I have firefox-dvmt but no firefox-dvmt1). If, later on, I want to make sure firefox-dvmt has the right prefs and features, I usually just run my script which will run create and configure. But the create will look for firefox-dvmt1 (not firefox-dvmt) and if not found, will create it; it then sets prefs and features on firefox-dvmt1 and then tries to rename it. Well, my old firefox-dvmt is still there, so that fails. I get to say “Steve you dumbass” and delete firefox-dvmt and firefox-dvmt1 by hand and rerun again.
Yes, I could solve this a bunch of different ways but they all would take some work and I’d rather wait to see if they can just fix the problem so I don’t have to rename VMs.