Proxmox Env Inventory

inder441

Member
Dec 17, 2024
31
2
8
Canada
github.com
Hello Team,

I have a huge setup of proxmox with around 50+ hosts and 1000+ VMs etc. I want to understand if there is a way to pull Proxmox inventory using some tool or mechanism. like list of VMs, host they are running on, etc, etc.
 
Looking for the same. We have tried using curl and the api tokens, as well as regular user logins to pull the information through the API, but there is never any data from query.
 
try this:

#!/bin/bash
# Proxmox VM inventory exporter

OUTPUT="proxmox_inventory.csv"

# Write CSV header
echo "VMID,Name,Type,Node,Status,CPU,Mem_Used,Mem_Max,Disk_Used,Disk_Max" > $OUTPUT

# Fetch VM list from cluster and format as CSV
pvesh get /cluster/resources --type vm \
| jq -r '.[] | [.vmid, .name, .type, .node, .status, .cpu, .mem, .maxmem, .disk, .maxdisk] | @csv' \
>> $OUTPUT

echo "Inventory written to $OUTPUT"
 
  • Like
Reactions: UdoB
try this:
Yes. At scale the cleanest approach is to query the PVE REST API and either consume it directly or wrap it with a small script. The one-call overview endpoint is “pvesh get /cluster/resources –type vm”, which returns every VM and container across the whole cluster with VMID, name, node (host it’s on), status, uptime, CPU, memory and disk; on any node you can turn that into a quick CSV with something like
 
  • Like
Reactions: Johannes S
You’re hitting three common gotchas at once: the header format, the query path, and token privileges. First, the Authorization header must contain the full token identifier including the user and realm, with no quotes and a single equals between the id and the secret. The correct form is Authorization: PVEAPIToken=USER@REALM!TOKENID=SECRET. If you send Authorization: PVEAPIToken=‘tokenid’=secret or omit USER@REALM!, Proxmox won’t parse it. Second, the endpoint should be /cluster/resources?type=vm (no trailing slash before the query string); the extra slash can trip some reverse proxies and, in older builds, return an empty list. Third, if your API token was created with Privilege Separation enabled, it has zero rights until you explicitly grant them to the token principal USER@REALM!TOKENID. In that case the call succeeds but the server filters everything you’re not allowed to see and returns {“data”:[]}. Either uncheck Privilege Separation so the token inherits the user’s privileges, or grant the token at least PVEAuditor on / (Datacenter) so it can see cluster-wide inventory.
 
  • Like
Reactions: UdoB
If I take out the ' ' for the token id, it fails because curl doesn't like the ! in it. If I flip it around it runs.

I took the trailing / out, but it still returns no data - looks like this now:

curl -k -s -X GET "https://hostname:8006/api2/json/cluster/resources?type=vm" \ -H 'Authorization: PVEAPIToken=user@realm!ro=secret'

I have tried this with both the priveledge separation and explicit perms for the token and without. Nothing seems to return data. Its very weird. if I login to the web interface as a user and go to the above url, it returns all the data.
 
When I run it with the -v, I see what could be the culprit I guess:
< HTTP/1.1 401 No ticket

I see referfences to having to use a ticket from another command sometimes?
 
DCM is something I would love to see evolving as a true data center manager. We cant group servers as per clusters etc. in DCM for now. it connects each host individually not as a cluster group etc. SO management for env like I have is tough. However, using curl and rest api I think is the way going forward for now.
 
for all intents and purposes this could be malware, so no thanks. not going to trust an unknown exe from a source without known good reputation without available sourcecode.
 
Last edited:
  • Like
Reactions: UdoB
Hi Beisser, I completely respect that stance. As a fellow sysadmin (who learned and deploy proxmox in entire infra of 3000+ VMs like 1.5 year back), I wouldn’t run a random binary without vetting it either. Security and 'trust-but-verify' are the foundation of what we do.

To provide some transparency since I am keeping the source proprietary for now (as i spent 2 months building this):
  • Zero Phoning Home: The tool is designed to work in air-gapped or restricted environments. It makes zero external calls except to the Proxmox IPs you provide in your local inventory.
  • VirusTotal/Sandboxing: I encourage anyone interested to run the binary through VirusTotal or a localized sandbox.
  • The 'Why': I built this to solve a specific 'sprawl' issue in global enterprise environments where I needed a portable, high-speed portal without a heavy footprint.
I know I’m a new face here, so I don't expect immediate trust. I'll be hanging around to answer any technical questions about the architecture or the Go/Fyne implementation. Cheers for the honest feedback :)