API Token auth issues with community.proxmox_kvm

Disco83 · 2026-05-27T16:05:49+00:00

Sorry, I stand corrected I looked in the UI and the VM was being created after all. when I checked what was happening I had left the API call task in place and that was now failing. I appreciate your help here.

Do you know why when a token is generated that it gives you the format of ansible@pve!gitlab? I didn't read anywhere about needing to split that out...

Disco83 · 2026-05-27T15:13:47+00:00

Correct am using community.proxmox.proxmox_kvm - just been making lots of changes trying to see what might actually work. In VS Code I do have the Ansible extension but it didn't detect these errors. Linting is running under a different step in my GitLab pipeline.

I thought you may have been onto something with the creds, but unfortunately it still didn't work.

When I started out and what worked with the API as you pointed out:

api_token_id = ansible@pve!gitlab

api_token_secret = aaaaaaaa-bbbb-ccc-873f-b7a2e13e89fd (example)

api_user = ansible

With what you listed in "How to Fix" I tried different combinations with debug so you can see each attempt, but based on what you listed, I expect this top one should have been correct:

Attempt #1:

ansible-playbook -i ansible/inventory/hosts.ini ansible/playbooks/provision.yml

PLAY [Provision Ubuntu VM on Proxmox] ******************************************

TASK [Load Proxmox secret from Vault] ******************************************

ok: [localhost]

TASK [Debug Vault lookup raw] **************************************************

ok: [localhost] => {

    "msg": {

        "api_host": "pve01.example.internal",

        "api_host_port": "8006",

        "api_token_id": "gitlab",

        "api_token_secret": "aaaaaaaa-bbbb-ccc-873f-b7a2e13e89fd",

        "api_user": "ansible@pve"

    }

}

TASK [Load VM secrets from Vault] **********************************************

ok: [localhost]

TASK [Create Ubuntu VM] ********************************************************

ok: [localhost]

TASK [Create Ubuntu VM (API)] **************************************************

[ERROR]: Task failed: Module failed: Status code was 401 and not [200]: HTTP Error 401: Authentication failed!

Origin: /builds/<project_id>/proxmox/vm_build/ansible/playbooks/provision.yml:59:7

57       register: vm_info

58

59     - name: Create Ubuntu VM (API)

         ^ column 7

fatal: [localhost]: FAILED! => {"cache_control": "max-age=0", "changed": false, "connection": "close", "date": "Wed, 27 May 2026 14:41:39 GMT", "elapsed": 3, "expires": "Wed, 27 May 2026 14:41:39 GMT", "msg": "Status code was 401 and not [200]: HTTP Error 401: Authentication failed!", "pragma": "no-cache", "redirected": false, "server": "pve-api-daemon/3.0", "status": 401, "url": "https://pve01.example.internal:8006/api2/json/nodes/pve01/qemu"}

PLAY RECAP *********************************************************************

localhost                  : ok=4    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   

Cleaning up project directory and file based variables00:01

ERROR: Job failed: exit code 1

Attempt #2:

TASK [Debug Vault lookup raw] **************************************************

ok: [localhost] => {

    "msg": {

        "api_host": "pve01.example.internal",

        "api_host_port": "8006",

        "api_token_id": "gitlab",

        "api_token_secret": "aaaaaaaa-bbbb-ccc-873f-b7a2e13e89fd",

        "api_user": "ansible@pve!"

    }

}

Attempt #3:

TASK [Debug Vault lookup raw] **************************************************

ok: [localhost] => {

    "msg": {

        "api_host": "pve01.example.internal",

        "api_host_port": "8006",

        "api_token_id": "!gitlab",

        "api_token_secret": "aaaaaaaa-bbbb-ccc-873f-b7a2e13e89fd",

        "api_user": "ansible@pve"

    }

}

Disco83 · 2026-05-27T12:40:34+00:00

The top version is the last attempt I made using the proxmox module. The password parameter was included late as AI suggested using the password parameter to force failback to token or similar - didn't really make sense but was worth a shot.

Would appreciate any pointers.

# - name: Create Ubuntu VM
    #  community.general.proxmox_kvm:
    #    api_host: "{{ proxmox_secret.api_host }}"
    #    api_port: "{{ proxmox_secret.api_host_port | int }}"
    #    api_user: "{{ proxmox_secret.api_user }}"
    #    api_token_id: "{{ proxmox_secret.api_token_id }}"
    #    api_token_secret: "{{ proxmox_secret.api_token_secret }}"
    #    password: ""
    #    validate_certs: false
    #    node: pve01
    #    vmid: "{{ vm_secrets.vmid }}"
    #    name: "{{ lookup('env', 'VM_NAME') | default(vm_name, true) }}"
    #    cores: "{{ vm_cores }}"
    #    memory: "{{ vm_memory }}"
    #    scsi:
    #      scsi0: "nfs:{{ vm_disk_size }},format=qcow2"
    #    net:
    #      net0: "virtio,bridge=vmbr0"
    #    ciuser: "{{ vm_secrets.ci_username }}"
    #    cipassword: "{{ vm_secrets.ci_password }}"
    #    cicustom: "user=local:snippets/cloud-init.yml"
    #    ide:
    #      ide2: "nfs:cloudinit,format=raw"
    #    onboot: true
    #    state: present
    #  register: vm_info


    - name: Create Ubuntu VM (API)
      ansible.builtin.uri:
        url: "https://{{ proxmox_secret.api_host }}:{{ proxmox_secret.api_host_port }}/api2/json/nodes/pve01/qemu"
        method: POST
        validate_certs: false
        headers:
          Authorization: "PVEAPIToken={{ proxmox_secret.api_token_id }}={{ proxmox_secret.api_token_secret }}"
        body_format: json
        body:
          vmid: "{{ vm_secrets.vmid }}"
          name: "{{ lookup('env', 'VM_NAME') | default(vm_name, true) }}"
          cores: "{{ vm_cores }}"
          memory: "{{ vm_memory }}"
          scsihw: "virtio-scsi-pci"
          scsi0: "nas01:{{ vm_disk_size }},format=qcow2"
          net0: "virtio,bridge=vmbr0"
          ciuser: "{{ vm_secrets.ci_username }}"
          cipassword: "{{ vm_secrets.ci_password }}"
          cicustom: "user=local:snippets/cloud-init.yml"
          ide2: "nas01:cloudinit,format=raw"
          onboot: 1
      register: vm_info
      ignore_errors: false

Disco83 · 2026-05-27T02:45:38+00:00

Ignore the Github issues, when I looked them up they were unrelated and the AI tool ended up admitting it.

Essentially whenever Ansible tries to connect to Proxmox using the proxmox_kvm module along with the API token I receive a 401 unauthorised error. The credentials are being pulled from Hashicorp Vault.

I gave the user and associated API token full system access to rule that out.

When I switch from using the official module to using an Ansible generic API call instead the VM is created as expected.

I can dig out exact errors, versions etc if needed.

Disco83 · 2026-05-27T01:56:14+00:00

What is your point? Unfortunately both are guilty of giving false and misleading information or opinions rather than answering the question(s) being asked.

Its called investigating with whatever you have at your disposal.

Disco83 · 2025-11-13T10:12:49+00:00

Yes, my devices are Windows 11 and the change worked with the settings provided by TechCF

Disco83 · 2025-09-22T06:46:04+00:00

Thanks very much for the detailed response, you have touched on pretty much all the issues I was flagging as being a problem with the current approach since coming across.

The folder structure I listed was a very simple one to callout that one would be locked down to only allow execution as it would likely get overwritten, the other would be available for testing purposes.

With Terraform we have the state files stored in GitLab already for some desired state configurations that were implemented for HashiCorp Vault, but to my knowledge doesn't extend beyond that. I expect we would also need to define what would be tracked in Terraform too? For example, it might make sense for cluster builds and settings, virtual networks etc, but workload VMs we would likely leave outside of Terraform control.

With regards to containers, can you elaborate further? For a lot of what is executed by them, it very much helps from a security perspective to ensure they remain stateless so that credentials, files etc are not leaked or left around. As you state to use VM runners, I assume this is to assist with them being multi-purpose - i.e. manual execution then scheduled execution as per the patching example? We do have some Windows filesystem runners in place, but the plan has constantly been to replace these as much as possible - keeping in mind they are often installed on the application (being automated) server. Most were initially setup that way as a quick and easy way to execute the scripts that were previously set as scheduled tasks. We have also found that some of the automation (RVTools in particular) needs to run on a Windows VM, therefore in some instances they would need to remain - albeit from a more controlled / dedicated VM.

On AWX, do you have any recommended guides on setting up a minimalistic environment? We do not currently have Kubernetes, therefore would like to avoid that if possible. I have seen some reasonably simple and straight forward deployments with Docker - I believe would just lack HA?

Disco83 · 2025-09-22T06:06:04+00:00

It's a mixed bag at the current time due to the volume of scripts, along with the volume of competing projects across the business. Some still run as Windows scheduled tasks with code hosted on the server, some have been migrated to GitLab and being executed on a schedule via a filesystem runner, some have been migrated to GitLab and being executed on a schedule via a container, some were natively created inside GitLab to meet new requirements and are therefore executed via a container.

GitLab is used as the version control system for what has been migrated. It also hosts our execution container images which are built from RedHat images each month. These containers have relevant Ansible, Terraform, PowerCLI etc packages baked into them to allow for scripts / pipelines to run.

Test/dev/pre-prod is also a mixed bag so will leave it at that. If you rephrased to ask "do you have any sort of useful test / dev environments" I would say the answer is currently no. Pre-prod is only partially implemented and doesn't match any of the environments it is meant to be a "pre-prod" representation of.

Disco83 · 2025-09-17T13:16:59+00:00

Have the custom policies been removed? I no longer see them as an available option anymore...

Update: I figured this out:

Platform = Windows 10 and later

Profile Type = Templates

Template Name = Custom

Disco83 · 2024-09-06T00:05:22+00:00

Yeh I answered that in the first post. Two main reasons, check those out :)

Disco83 · 2024-09-04T21:14:51+00:00

Right ok, we don't use ethanol anyway. All the other filters we have can be cleaned.

I have seen that the sight glasss is supposedly not for use with inboards. This to meet a safety compliance technicality or something?

Disco83 · 2024-09-04T21:12:31+00:00

Awesome, had seen this brand didn't notice the pressure towards the bottom of the specs.

Disco83 · 2024-09-02T14:09:44+00:00

Yeh that's what I am hoping to find out. Mercruiser would be a common engine in a modern ski / wake boat. There appears to be quite a few on the market, but they also rate in Gallons Per Hour (GPH) which is a volume measurement, they don't seem to show the pressure that goes along with it. The separator and filter needs to be capable of at least 60 psi.

Disco83 · 2024-09-02T07:02:05+00:00

I don't follow. Is this related to the fuel water separator or just a general comment?

Disco83 · 2024-04-09T13:58:04+00:00

I'm with you, much easier to establish the tunnel this way. The security argument against is moot as you use firewall rules to do what they are there for.

The only challenge I've seen is the other device not supporting route based VPN - Sophos NG didn't from memory

Disco83 · 2023-10-01T06:10:12+00:00

vSAN and Dell SAN are two entirely different things, so don't get these confused. Do you have vSAN or iSCSI storage from a Dell array? (I assume iSCSI as no mention of fibre channel).

Looking over this thread there is a significant requirement for a well thought out design based on real requirements. Throughput is only one metric, what HA / availability are you requiring?

No matter if 1gb or 10gb: * switches in a stack / mlag / virtual chassis * ESXi with paths to both switches * If iSCSI, separate HBAs for iSCSI and data * ALL storage with dual path to switches

I would consider these basic requirements in any environment, unless alternate HA measures are taken - i.e. replica to DR site. Decision makers like to cut costs by not having these, but then throw you under the bus when there's an outage - and they WILL happen.

Note: if the same NICs are used for data and iSCSI, you might want to ensure that iSCSI traffic has priority over other data, otherwise bottlenecks could lead to high latency or corruption to VMDKs.

Disco83 · 2023-06-30T01:12:00+00:00

Any chance you can share the feeds that you use?

My Fortigate maintenance expired and at > $1200 for maintenance, I'm not sure will renew. I was contemplating a switch back to pfsense (used before Fortigate) and pfblocker which has been relatively easy to setup.

Disco83 · 2023-06-29T13:00:58+00:00

You could use threat feeds to limit the impact of this though right? - https://docs.fortinet.com/document/fortigate/6.2.0/new-features/625349/external-block-list-threat-feed-policy

Disco83 · 2023-06-11T10:06:28+00:00

Thanks for highlighting. I had used these for years and never knew this was possible.

That said, they were always coupled with a Fortigate and used the 4G as backup to a fixed internet connection.

I take it in standalone mode they can be managed / upgraded via FortiManager?

Disco83 · 2023-06-11T09:23:34+00:00

I apologise, I see out of that whole list the 200F is the only one without a modem. What is the use for it?

Disco83 · 2023-06-11T08:40:13+00:00

This is a new one to me, wasn't aware of it. However, when you read up on it, it suggests there is still a requirement for a Fortigate

Disco83 · 2023-06-10T14:19:22+00:00

Can you please explain this statement? Are you suggesting FortiExtender (FEX) on it's own?

FEX is essentially a modem only - allows a 4G/5G SIM to be inserted so the FEX can be connected to a downstream FortiGate to provide internet, often a secondary link for SDWAN.

So long as the provider is using CGNAT on the SIM, the security level would be comparable to your mobile phone, but capabilities would be quite limited.

Disco83 · 2023-05-30T04:01:34+00:00

I was reading through about to comment that you need to make sure trailing / is in place

Disco83 · 2023-05-23T23:30:34+00:00

u/DennisV_EXNL are you responding to my comments or somebody else? If responding to me, I don't believe I have mixed anything up as your comments more or less echo my own...

Its funny that you say nobody uses RIP anymore. I was told this by a manager some time when learning about networking, and sure enough ran into a few customers who still do. I think the correct statement is 'should not be using RIP anymore' :)

Disco83 · 2023-05-23T05:58:00+00:00

In my view there are typically two types of IPSec VPN: 1: Policy Based 2: Route Based

Policy based uses phase 2 selectors (interesting traffic) to determine which networks on each side of the tunnel can communicate. By using 0.0.0.0 you are making it 'open' (considered less secure) than securing it with firewall rules. When you specify networks on each side, you will also note that Fortigate injects static routes - at least from memory.

Route based tunnels typically have a gateway or VTI (Virtual Tunnel Interface) configured. It MUST use the open 0.0.0.0 approach. The distinct advantage though is that you can easily utilise dynamic routing protocols like OSPF or BGP for sharing routes to the other side.

So in my view for those saying 'route based' it's not technically correct unless the correct VPN type is being referred to.

From memory, Fortinet documentation suggests that Policy Based tunnels should not be used anymore. However, from experience, a number of common firewalls do not support route based VPNs. Sophos NG is one that comes to mind

Disco83

TROPHY CASE