[SOLVED] REST API not setting IPV4 address for LXC container

[simonjcarr]

I have a working REST API Connection to proxmox. I can create and clone an LXC container just fine using the API.

After cloning a container, I am trying to use the REST API to set the containers IP Address, but it's not working. My NodeJS code is below.

let formBody = await this.getFormBody({net0: "name=eth0,bridge=vmbr99,ip=192.168.22.1/20,gw=192.168.16.1"})
const proxmoxResponse = await fetch(`https://cloud1.xxxxx.com:8006/api2/json/nodes/cloud1/lxc/${vmid}/config/`, {
    method: "PUT",
    headers: {
        Authorization: "PVEAPIToken=simon@pam!xxxxxx-automation=xxxxxxxxxxxxxxxxxx",
        "Content-Type": "application/x-www-form-urlencoded;charset=UTF-8",
        Accept: "application/json"
    },
    body: formBody
})
const responseData = await proxmoxResponse.json()
console.log("issueIpV4: ", responseData)

The response I get from the above from the sever is

{ data: null }

I am sure I am hitting the correct API endpoint, because if I change the field name from net0 to something not recognised by the API for that endpoint it gives me an error

{
  data: null,
  errors: {
    ffnet0: 'property is not defined in schema and the schema does not allow additional properties'
  }

Can someone provide an example of changing an LXC container IP address using a REST API call.

 

[fabian]

PUTting a config update doesn't return the config but an empty (successful) response.. you need to GET afterwards (same API path)

 

[simonjcarr]

@fabian I was using the ProxMox GUI to see that the IP Address had not been set, however I have found the problem.

I was making the API call to set the IP Address following an API call to clone an existing container. It turns out the failure to set the IP Address was because the new VM had not had chance to be created when the second API call was made. Putting a delay in the second call fixed the issue. I know need to update my code to recursively check for the existence of the VM before making the second API call.

Thanks

 

[t.lamprecht]

@fabian I was using the ProxMox GUI to see that the IP Address had not been set, however I have found the problem.

I was making the API call to set the IP Address following an API call to clone an existing container. It turns out the failure to set the IP Address was because the new VM had not had chance to be created when the second API call was made. Putting a delay in the second call fixed the issue. I know need to update my code to recursively check for the existence of the VM before making the second API call.

Thanks

FYI, you should get an "UPID" returned from the create call as it spawns a task-worker, and you can use that UPID to poll the status of said task through the "/nodes/localhost/tasks/$upid/status" call, e.g. checking its status property for stopped and may additionally the exitstatus in that case.

https://pve.proxmox.com/pve-docs/api-viewer/index.html#/nodes/{node}/tasks/{upid}/status

 

[fabian]

@fabian I was using the ProxMox GUI to see that the IP Address had not been set, however I have found the problem.

I was making the API call to set the IP Address following an API call to clone an existing container. It turns out the failure to set the IP Address was because the new VM had not had chance to be created when the second API call was made. Putting a delay in the second call fixed the issue. I know need to update my code to recursively check for the existence of the VM before making the second API call.

Thanks

in addition to what thomas said - in that case you should have gotten an error (for the JSON API via the HTTP status code & message, the extjs API formatter used by the GUI encodes errors in the response body) - likely because locking was not possible since the clone still held the lock for the VM config..

 

[bl4ckarch]

Well i don't know if i should create a new issue but it falls under this category, well i am writing a webservice using this proxmox api and upon creating a vm (lxc containers) when the creation actually works i receive as response {UPID:eh017:000E0A66:2787A3E3:65FBEC07:vzcreate:1015:API@pve:} this means it worked but the actual 'probleme' i encounter is that whenever the lxc already exist || if there is no template available i don't actually get the response with the corresponding correct reason why the call failed and it is a little bit embarassing not to treat have a debuglike response as if i was trying to create from the GUI

 

[fabian]

please check the full response, like I wrote above, depending on the formatter you use the error might be in the body or in the header..

 

[bl4ckarch]

yeah, what i am trying to say is that there is actually no task made when there is this type error occurs, (may be the api does not actually responds with a full clear response) or simply because in the gui you can't actually create a lxc with a CTID that already exist from start only the create panel

 

[fabian]

yeah, if the API handler encounters a fatal error before it forks the worker task then there will be no task, but the API request will still return an error..

 

[fabian]

for example with the extjs formatter, directly in the returned object:

< HTTP/1.1 200 OK
< Cache-Control: max-age=0
< Connection: close
< Connection: Keep-Alive
< Date: Thu, 21 Mar 2024 10:03:46 GMT
< Pragma: no-cache
< Server: pve-api-daemon/3.0
< Content-Length: 115
< Content-Type: application/json;charset=UTF-8
< Expires: Thu, 21 Mar 2024 10:03:46 GMT
<
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
{"data":null,"message":"unable to create VM 105 - VM 105 already exists on node 'yuna'\n","success":0,"status":500}%

with the json formatter, as part of the respone:

< HTTP/1.1 500 unable to create VM 105 - VM 105 already exists on node 'yuna'
< Cache-Control: max-age=0
< Connection: close
< Date: Thu, 21 Mar 2024 10:02:58 GMT
< Pragma: no-cache
< Server: pve-api-daemon/3.0
< Content-Length: 13
< Content-Type: application/json;charset=UTF-8
< Expires: Thu, 21 Mar 2024 10:02:58 GMT
<
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
{"data":null}%

this is with curl, but any HTTP client should allow you to access this information somewhere..

 

[bl4ckarch]

for example with the extjs formatter, directly in the returned object:

< HTTP/1.1 200 OK
< Cache-Control: max-age=0
< Connection: close
< Connection: Keep-Alive
< Date: Thu, 21 Mar 2024 10:03:46 GMT
< Pragma: no-cache
< Server: pve-api-daemon/3.0
< Content-Length: 115
< Content-Type: application/json;charset=UTF-8
< Expires: Thu, 21 Mar 2024 10:03:46 GMT
<
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
{"data":null,"message":"unable to create VM 105 - VM 105 already exists on node 'yuna'\n","success":0,"status":500}%

with the json formatter, as part of the respone:

< HTTP/1.1 500 unable to create VM 105 - VM 105 already exists on node 'yuna'
< Cache-Control: max-age=0
< Connection: close
< Date: Thu, 21 Mar 2024 10:02:58 GMT
< Pragma: no-cache
< Server: pve-api-daemon/3.0
< Content-Length: 13
< Content-Type: application/json;charset=UTF-8
< Expires: Thu, 21 Mar 2024 10:02:58 GMT
<
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
{"data":null}%

this is with curl, but any HTTP client should allow you to access this information somewhere..

yeah that true for the api the response is actually in the HTTP header and i got it from there, I realized that PVE API returns error message in the "status line" of HTTP response. That was my mistake to not realize it earlier and to be honest, I've never seen an API server actually do that before. Therefore, I kept being confused by empty response body, not realizing the error message was in the status line instead of the body.
now it is clear
```
"success": false,
"errors": [
{
"code": 0,
"message": "HTTP Status Line: 500 0"
},
{
"code": 0,
"message": "Response Headers: HTTP/1.1 500 CT 1013 already exists on node 'eh017'\r\nCache-Control: max-age=0\r\nConnection: close\r\nDate: Thu, 21 Mar 2024 10:04:48 GMT\r\nPragma: no-cache\r\nServer: pve-api-daemon/3.0\r\nContent-Length: 13\r\nContent-Type: application/json;charset=UTF-8\r\nExpires: Thu, 21 Mar 2024 10:04:48 GMT\r\n\r\n"
}, ```

 

[fabian]

like I said, you can control that behaviour by using the formatter you want (the part right after api2 in the URL). the web UI uses the "extjs" formatter which will return 200 and put such errors into the returned object..

 

[bl4ckarch]

like I said, you can control that behaviour by using the formatter you want (the part right after api2 in the URL). the web UI uses the "extjs" formatter which will return 200 and put such errors into the returned object..

Thanks for your help and time, to help me throught out this