really great video. Lots of information, well explained and presented. Only the meaning of the variable creation was not clear to me. Why don't you just create the variables in a file without the hassle of putting them together? You don't gain any flexibility that way, or am I missing something here?
For me it's a bit more flexible as I can maintain each VM independently and I don't end up with one big file If I no longer need a VM I can delete its file and next time it won't get added into the master file If everything is in one file I'll have to search for the specific set of information to remove Of course, if I want to add a new VM I just need to add a new file
@@TechTutorialsDavidMcKone thanks for the clarification, i can understand that very well. I simply packed the desired vms into a global variable file. However, I also make my own ansible script for each rollout. What remains is that your video was a great introduction to working with proxmox, thanks again.
Where did you find that import-from property in the scsi section when creating the host? That's not documented in the community.general collection, but I think it will solve a problem I had with this where I had t be root (not root API token, ROOT) to import the disk image because only root can import from a raw disk path. That's a really nice fix for that which I will be trying RIGHT NOW. Thanks.
Ansible modules are usually just overlays for commands You can do a lot with Proxmox using the qm command pve.proxmox.com/pve-docs/qm.1.html In there you'll find information about options like "import-from"
@@TechTutorialsDavidMcKone I hadn't looked at the module code or the qm CLI which is surely just wrapping the API. I stopped at the community.general docs where it said "it supports these properties", and its lists literally TWO out of the nearly FORTY that are in the qm create section of the manpage. I need to go make a pull request on those docs. Thanks again.
I'm hoping to have everything under the control of Ansible But I know some systems don't offer unattended installs so it could be tricky Hmm..I wonder if I should ask ChatGPT to handle those ones...
@@TechTutorialsDavidMcKone At the moment, as the last step of a rollout, I name the new computers using Ansible and enter their hostname and IP in the BIND-DNS server using Ansible, too, so that my entire rollout works via Ansible. So I have a separate rollout for each role, whether web server, file server or database server 🙂 I hope you can understand my English to some extent
Would you consider an update to this that is more AWX or include dynamic cars? I. E. Query the user for vmname, vmid, CPU, memory, disk size, ipaddress, mask and gateway?
Probably not because my long term goal is to just set up Ansible to configure and maintain everything using a few playbooks I prefer to keep things simple, so the aim of the playbooks is to just build the VMs from the ground up, install the relevant application software to each VM and then just regularly apply software and config updates
@@TechTutorialsDavidMcKone my goal too, but I didn't want to have to make changes, commit, sync to AWX then deploy. AWXs survey tools eliminate some of if those steps...
@@JamesTremblay I opted for a simple cron job solution basically, using Semaphore So I setup and maintain Ansible as normal but then Semaphore runs the playbook(s) This way I don't touch Semaphore anymore, unless there's an alert to say a task didn't run for instance
@@JamesTremblay I have VM files which define the "hardware" specs of each VM I want So if I want to create a new VM I create a new file and the build playbook will create that VM the next time it runs But that only goes as far as the OS installation and some basic settings to make sure only Ansible has access to the VM through SSH The maintenance playbook is next and covers applications and configurations All VMs in the inventory are updated with common settings like time, SSH, etc But each application group has its own specific software and the configs that go with it So new VMs will get software installed and it will be configured, while existing VMs will have config updates if needed It's what I like most about Linux as the config files are text files, so it's easy to upload a change and restart a service
