Thank you for this constructive argument
Have a nice day.
Thank you for this constructive argument
Have a nice day.
This should work:
xe vm-param-set uuid="$uuid" \
xenstore-data:vm-data/ip="$ip" \
xenstore-data:vm-data/netmask="$netmask" \
xenstore-data:vm-data/gateway="$gateway"
Optionally the default DNS server can be replaced as well:
xe vm-param-set uuid="$uuid" xenstore-data:vm-data/dns="$dns"
Don't forget to restart the XOA afterward!
@markhewitt1978 Hi, thank you for your feedbacks!
We are aware that this limitation bothers a lot of users and we have plan to address that in the next major version of XO.
XO 5 was already a major improvement over its predecessor because it allows viewing and handling a much bigger infra.
XO 6 will go further in this direction by introducing a tree view and the possibility to edit and handle many objects at the same time.
@Danp That may not be directly to script but to the external environment: SMB works much better if cifs-utils
is installed on the system, something that is present on our doc but might be missing in some install scripts.
We have no animosity whatsoever regarding these scripts but we prefer our appliances (or even manual installs from our documentation) because we understand much better what's going on and it's easier to replicate and fix the issues
Regarding your idea of including the commit identifier for the source version, that's not a bad idea, a (as simple as possible) implementation in a PR would be welcome
@M92 There is now a /groups
collection which lists all the groups and two new collections, /groups/:id/users
and /users/:id/groups
which list respectively all users in a group and all groups a user belongs to.
These new collections have the same behaviours than the others, which means they accept the fields
, filter
and limit
parameters.
And yes the limit
parameter should work correctly, let me know if you have any issue.
@M92 Hello, no, groups are not exposed at this time, will do it ASAP.
@olivierlambert Done: https://github.com/vatesfr/xen-orchestra/commit/33b45d2eda2ce6d8071541da246bdcfd06b133b8
It's not perfect but that should help
Example:
vm.start
{
"id": "123e4f2b-498e-d0af-15ae-f835a1e9f59f",
"bypassMacAddressesCheck": false,
"force": false
}
{
"errors": [
"R620-L3: VM_REQUIRES_SR(OpaqueRef:21fa00fc-62ce-4694-8b49-fcecd600a89e, OpaqueRef:4dd615a7-9a8c-4698-aceb-c10f782321c8)",
"R620-L1: HOST_NOT_ENOUGH_FREE_MEMORY(216430280704, 18778341376)",
"R620-L2: VM_REQUIRES_SR(OpaqueRef:21fa00fc-62ce-4694-8b49-fcecd600a89e, OpaqueRef:4dd615a7-9a8c-4698-aceb-c10f782321c8)"
],
"message": "",
"name": "Error",
"stack": "Error:
at Xapi._startVm (file:///home/julien/dev/vatesfr/xen-orchestra/packages/xo-server/src/xapi/index.mjs:1358:15)
at Xapi.startVm (file:///home/julien/dev/vatesfr/xen-orchestra/packages/xo-server/src/xapi/index.mjs:1393:7)
at Api.callApiMethod (file:///home/julien/dev/vatesfr/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:307:20)"
}
@olivierlambert It's a limitation of CRON patterns, to support this we need to implement it separately and design a dedicated UI.
@felibb We've been unable to reproduce so far, I'm waiting for someone else confirmation before attempting to fix it on master.
If you can, please test the xen-api-blocking
branch and let me know if that helps.
XO does not pause backups during upgrades/restart, all currently running backups will be interrupted as @olivierlambert said.
An interrupted backup is not a big problem by itself, nothing will be broken, and the next run will run properly.
Backups are only run at the time they are scheduled, if XO is offline at this time, it will not automatically run them when restarted, it will wait for the next scheduled run.
@Dude417 Hello, you need to use the format
param for that:
xo-cli vm.export vm=a01667e0-8e29-49fc-a550-17be4226783c format=ova @=vm.ova
I've also just added OVA support for VM export in the REST API: https://github.com/vatesfr/xen-orchestra/blob/master/packages/xo-server/docs/rest-api.md#vm-import
Thank you for your report, it should now be fixed: https://github.com/vatesfr/xen-orchestra/commit/29f6f92ad3ce2f22b2d5929c2b3e7d1de938729a
Stats are usually not working due to a misconfigured backup network on the pool, I've added an entry in our documentation for it: https://xen-orchestra.com/docs/troubleshooting.html#stats-not-working
@rmarion If you are seeing this on a an XOA, open a support ticket and a support tunnela and we'll investigate directly
@olivierlambert No, CRON patterns does not support this kind of scheduling.
@olivierlambert It's a limitation of CRON patterns, to support this we need to implement it separately and design a dedicated UI.
@Rhodderz I'm not able to reproduce the issue on my side.
I successfully filtered VMs by a /foo
tag and was able to filter for it (tags:/^\/foo$/
) in the REST API, either by using filter=tags%3A%2F%5E%5C%2Ffoo%24%2F
(encoded with encodeURIComponent()
) or by using filter=tags:/%5E%5C/foo$/
(encoded using encodeURI()
which does not encode /
or :
).
Thanks for the report, it should be fixed, let us know if that's not the case
https://github.com/vatesfr/xen-orchestra/commit/aa6b23c06cf2056600cdabaaa1705ab1067ed2a9