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

[linux]

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

 

[bbgeek17]

"pveproxy" is the process thats listening to your HTTP API requests:

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

 

[linux]

Your module should, hopefully, have a way to debug failed requests.

This is what we're working on at the moment. I was hopeful that pveproxy stashed request data as well. No worries.

Thank you for your reply!

 

[linux]

We're getting Parameter Verification Failed for the below request parameters to create a Linux Container - any thoughts as to why?

(
[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
)

 

[bbgeek17]

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

 

[linux]

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?

 

[fiona]

Hi,

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?

thanks for the report! I do agree and sent a patch: https://lists.proxmox.com/pipermail/pve-devel/2023-June/057597.html

 

[linux]

thanks for the report! I do agree and sent a patch: https://lists.proxmox.com/pipermail/pve-devel/2023-June/057597.html

Thank you! Will that update the API Viewer for LXC and QEMU once approved?

 

[fiona]

Thank you! Will that update the API Viewer for LXC and QEMU once approved?

Not directly, but once the pve-docs package is also regenerated. The api-viewer gets its info from the JSON schema.

 

[linux]

Not directly, but once the pve-docs package is also regenerated. The api-viewer gets its info from the JSON schema.

Perfect, I was hopeful that you had it configured in your pipeline. Thank you once more! (edit: I can see the new range now)