@lsouai-vates After updating I still see the inconsistency, if it helps. I'll stick to the swagger doc if that's the correct source of truth. I was only querying this way because the docs suggested it as a method.

Is there a place I can submit a feature request to allow setting a description and other settings from the UI to get feature parity when creating a VM? Otherwise, there's not much point since I have to go in and touch the new VM anyway. Unless I'm going about this wrong to begin with?

@lsouai-vates I'm using from XOA, not from source. Should I be using latest instead of stable?

@lsouai-vates said in Trouble Creating VM via API:

@bryonadams I understand your point of view and the reasoning behind it. However, it’s not always an absolute rule that every field returned by a GET endpoint can be passed back to a POST (or PUT).

Sorry, I don't think I was clear. The keys are different for the same thing. Depending on where you look, autoPowerOn or auto_poweron is returned.

eg:

• ..rest/v0/pools/_/actions/create_vm/ returns the key "auto_poweron",
• /rest/v0/vms/de320b24-d768-50f4-6226-b48f64f85a55 (my example vm) returns the key "auto_poweron"
• Swagger doesn't seem to have this key as far as I can tell, unless I'm looking at the wrong thing. I only see a way to filter by tags.

@lsouai-vates said in Trouble Creating VM via API:

Indeed, it also seems you’re not running the latest version of XO. Could you please check again? You should be getting the recent REST API updates:

I don't know how I can be more up to date than up to date.

@olivierlambert That worked, and is exactly what I was looking for in the API docs but overlooked. Are there plans to put this type of API explorer/documentation on the documentation website or is the expectation that we'll interact with XO directly for documentation of API endpoints?

@lsouai-vates said in Trouble Creating VM via API:

name_description and memory are accepted but the auto_poweron parameter is not allowed because it is misspelled... the API expects autoPoweron.

Sorry, I was responding to this in particular. I was taking auto_poweron straight from the API GET endpoint. Keys or values from a GET should be usable in a POST. If these values aren't accepted during creation then it's moot, though I think description should be allowed to override so that a VM can have a meaningful description.

@lsouai-vates said in Trouble Creating VM via API:

@bryonadams, have you checked the API Swagger?

I'm not sure how to get this, I tried via web browser and just get a "Cannot GET /docs/" message.

@lsouai-vates
Xen Orchestra is telling me I'm up to date, nothing available according to the UI.

- node: 20.18.3
- npm: 10.8.3
- xen-orchestra-upload-ova: 0.1.6
- xen-orchestra-web: 0.21.1
- xo-server: 5.181.0
- xo-server-telemetry: 0.7.0
- xo-server-xoa: 0.31.2
- xo-web-free: 5.178.0
- xoa-cli: 0.40.3
- xoa-updater: 0.50.10

Also, auto_poweron is what I used because that's what the API returns as the method. That should return a key that I can functionally copy/paste into a POST. See the below GET for the actions on create_vm. The error handling is not returning helpful messages if the three keys I used are invalid for different reasons.

It looks like if I exclude those three values it makes the VM. So maybe the better question is; if I'm taking these values from the template, am I not meant to override them? The description seems like an odd one to not be able to override if that's how it works.

I'm very new to doing things with APIs and running into this error. What exactly does "is an excess property and therefore is not allowed" mean as a response? Below is the body I'm sending via Bruno client. I'm sure I'm missing something simple, the docs were a bit of a struggle though.

Endpoint is https://xo.ducknet.org/rest/v0/pools/3c6777fc-e8d8-e065-7c30-37eb2800f472/actions/create_vm/

{
  "auto_poweron": true,
  "boot": false,
  "memory": 1073741824,
  "name_description": "test_desc",
  "name_label": "test_label",
  "template": "3ceb66f7-c137-ef4a-7a06-9af524ed5110"
}

Full response

{
  "error": {
    "body": {
      "message": "\"auto_poweron,memory,name_description\" is an excess property and therefore is not allowed",
      "value": {
        "name_description": "test_desc",
        "memory": 1073741824,
        "auto_poweron": true
      }
    }
  }
}

@AtaxyaNetwork It is Debian 12. I found the problem and will post again if there's more issue. The VM stopped using its static IP, not sure how that happened, but I re-added it to /etc/network/interfaces and it's working again.

@Andrew It's the same. It should respond with a 302 to /signin as the login page. It is listening on :80 too, I just forgot it in my filter. I'll edit the correct filter in the post.