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.
@fataugie Should be fixed, let me know if there are any issues left!
https://github.com/vatesfr/xen-orchestra/commit/194db8d0dd28ccfd058c97e8c16b32d853b26cf8
@XCP-ng-JustGreat Thank you for your report, it should be fixed
@magentinos All collections are listed when you get /rest/v0
, amongst them there is the vm-templates
collection.
@DustyArmstrong Fixed: https://github.com/vatesfr/xen-orchestra/commit/b0c37df8d73beb9589dc28e32d5a4409a48a9272
Let me know if you have any issues.
Thank you for your report, it should now be fixed: https://github.com/vatesfr/xen-orchestra/commit/29f6f92ad3ce2f22b2d5929c2b3e7d1de938729a
I confirm this bug, it happens when editing a job and changing its method, the previous params are incorrectly kept.
I'm checking whether it's easy to fix.
@stucamp I finally had time to investigate this, it should now be fixed
Thanks for your report!
https://github.com/vatesfr/xen-orchestra/commit/24cac9dcd5d83c3170175c9c874d0a3ae51f4e6d
Hello everyone,
We have been using Yarn 1 in XO because it had support for workspaces, which npm
lacked at the time.
But now that npm
has caught up, and Yarn 1 is frozen, I think it's time to get back to using it.
Also, we are thinking about using Turborepo instead of our own custom scripts to build the repository. This would, among others, bring caching, i.e. packages are no longer rebuilt if there were no changes.
I hope these changes will not introduce any problems (I'm thinking about https://xcp-ng.org/forum/post/54567).
I you want to test, please take a look at this PR: https://github.com/vatesfr/xen-orchestra/pull/6559
Keep me posted if you have encounter any issues
@maverick Aggressive (even passive) comments are not tolerated here.
We are doing what we can and are open to questions, suggestions and even better, contributions.
On your other thread, you are suggesting a solution, which is a better approach to this kind of problems, we'll try to look into it and if it's easy enough and does not cause other issues we may integrate it.
In the mean time, you can add the following setting to your xo-server
's config to keep the previous behavior:
[backups]
useGetDiskLegacy = true
Let us know if you have issues.
Thank you for your reports, we have pinpointed the issue and we'll fix it soon