[SOLVED] LXC/QEMU via API - Parameter Verification Failed - Request params seem OK though?

L

linux

Member
Dec 14, 2020
96
36
23
Australia
Hi there,

We're troubleshooting a module which talks to Proxmox to provision VMs/CTs.

In the pveproxy log we can see the request come in and get a 400 response for the actual creation attempt. Getting a ticket, etc, is OK (200).

Trying to work out the 'why' there, we're trying to find more information about the specific request that was made (arguments and so on).

Is this something that Proxmox stores as well? If so, how do we find it?

Cheers,
Linux
 
Last edited:
"pveproxy" is the process thats listening to your HTTP API requests:
Code: 
netstat -ltnp|grep 8006
tcp6       0      0 :::8006                 :::*                    LISTEN      1190/pveproxy

It logs high level access information in /var/log/pveproxy/access.log , however that wont contain request details. You might be able to glean some information from "journalctl -f".
Your module should, hopefully, have a way to debug failed requests. If you are dead set on debugging this on server side, your only choice may be to modify pveproxy code to dump more verbose information.

Good luck

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
We're getting Parameter Verification Failed for the below request parameters to create a Linux Container - any thoughts as to why?

Code: 
(
[vm_settings] => Array
(
[vmid] => 97
[ostemplate] => local:vztmpl/ubuntu-20.04-standard_20.04-1_amd64.tar.gz
[swap] => 512
[rootfs] => local:8
[bwlimit] => 0
[net0] => bridge=vmbr0,name=eth0,ip=a.b.c.d/24,gw=a.b.c.d
[nameserver] => 1.1.1.1 1.0.0.1
[password] => 12345678
[cpuunits] => 1024
[cpulimit] => 1
[memory] => 512
)
 
Last edited:
There is not enough information to help. Without knowing how it all gets encoded and what the final result is, many things will depend on the language/library/framework etc.
I would suggest:
a) reduce request to required parameters only, if possible. That will test basic functionality.
b) use pvesh/curl to execute the request with all parameters. This will confirm full functionality of a known good client.
If (a) and (b) work, then its your module/client and only you and its author can work it out.

things that are more suspect than others are multi word strings, are they getting properly wrapped?

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Last edited:
Problem was the API Viewer saying that vmid was 1-N when in actual fact it is 100-N.

Once we re-submitted with a vmid >100 it was OK. API Viewer says otherwise!

I was also curious about the DNS, though I suppose it didn't relate.

@fiona - do you agree re: the above disparity?
 
linux said:
Thank you! Will that update the API Viewer for LXC and QEMU once approved?
Click to expand...
Not directly, but once the pve-docs package is also regenerated. The api-viewer gets its info from the JSON schema.
 
fiona said:
Not directly, but once the pve-docs package is also regenerated. The api-viewer gets its info from the JSON schema.
Click to expand...
Perfect, I was hopeful that you had it configured in your pipeline. Thank you once more! (edit: I can see the new range now) :D
 
Last edited:
You must log in or register to reply here.
Top Bottom