Subcategories

• Management

  VMs, hosts, pools, networks and all other usual management tasks.
  476 Topics

  4k Posts

  A

  So if i set VMs to Best-effort or disabled for HA i get not enough memory. @pkgw Do you have Twinstore configured and/or HA enabled? If no I will continue my issues at the twinstore post. If i set to restart i get this.... host.setMaintenanceMode { "id": "35233210-4e37-4703-9bf6-9e8a9c24df9f", "maintenance": true } { "code": "HA_OPERATION_WOULD_BREAK_FAILOVER_PLAN", "params": [], "call": { "duration": 5, "method": "host.disable", "params": [ "* session id *", "OpaqueRef:d9bd976f-445c-8244-1b56-879f446efc12" ] }, "message": "HA_OPERATION_WOULD_BREAK_FAILOVER_PLAN()", "name": "XapiError", "stack": "XapiError: HA_OPERATION_WOULD_BREAK_FAILOVER_PLAN() at XapiError.wrap (file:///opt/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12) at file:///opt/xen-orchestra/packages/xen-api/transports/json-rpc.mjs:38:21 at runNextTicks (node:internal/process/task_queues:65:5) at processImmediate (node:internal/timers:472:9)" }
• Advanced features

  ACLs, Self-service, Cloud-init, Load balancing...
  105 Topics

  864 Posts

  M

  Is a centralized XOA server "managing" two remote Proxy-fronted XCP clusters supported with the SDN Controller Plugin? We are looking to deploy an architecture similar to this blog post from 2022: https://xen-orchestra.com/blog/xo-proxy-a-concrete-guide/
• Backup

  All XO backup features: full and incremental, replication, mirrors...
  515 Topics

  5k Posts

  I

  Hi @simonp. The problem is gone with commit 44e5b!!! Up-to-date XCP-NG host and XenOrchestra VM were restarted after updating XenOrchestra. I just initiated a full backup and all VMs - including my problematic machine - were backed up successfully without error. Awesome! I will wait with closing until the scheduled delta backup is completed successfully, too. Edit: Scheduled backup ran without issue. The problem seems to have been resolved! Thanks for all your work and assistance Regards, Marc
• REST API

  Everything related to Xen Orchestra's REST API
  86 Topics

  645 Posts

  J

  Hello I'm pulling stats for all VMs to understand CPU usage. We're a bit behind the curve in terms of XO versions, but these questions hopefully are still relevant. If using a granularity of days, the interval is set to 86400 (understandably) but the endTimestamp varies. Running this on June 9th @ ~1740 we get timestamps for both Mon Jun 8 01:00:00 AM BST 2026 and Tues Jun 9 01:00:00 AM BST 2026. Does this average across the day? Why is the timestamp 0100? Why would there be different timestamps between VMs (all are running) and does that mean that the figures are misaligned in the results? These are retrieved via curl and a bash script, a bit hacky, but for clarity the request is: ++ curl -X GET -s -H accept:application/json -b authenticationToken=[[REDACTED]] -o [[REDACTED]] 'https://[[REDACTED]]/rest/v0/vms/[[REDACTED]]/stats?granularity=days' Really keen to know if we can control the start and endtime, as well as provide a manual interval, as well as the aggregation strategy (min, max, average). Are any of these possible? Lastly, is cpuUsage the percentage as per the dashboard, but averaged over all CPUs? Thanks so much in advance. James
• Infrastructure as Code

  Terraform, Packer or any tool to do IaC
  51 Topics

  471 Posts

  P

  The Kubernetes CSI driver for Xen Orchestra just hit v0.4.0, and we want it on more real clusters before it reaches a stable release candidate. If you run Kubernetes on XCP-ng VMs, this is a good time to give it a proper workout. What's new in v0.4.0: Local-storage support Automatic pool-discovery fallback Kubernetes metadata now lives in Xen Orchestra VDI tags instead of the deprecated other_config. That change also drops the old requirement for Xen Orchestra 6.4 or newer, so the driver runs on more deployments now. ️ Read this before you upgrade. v0.4.0 is a breaking change. The Kubernetes metadata moved from other_config to VDI tags, so you must migrate before upgrading from v0.3.0. Do not upgrade in place: follow the v0.3.0 to v0.4.0 migration guide in the release notes, then move to v0.4.0. What helps us most is hearing how it behaves on your own setup: what works, what breaks, which storage backend you use, and which flavour of Kubernetes you run (k3s, full k8s, or something else). Edge cases on real clusters are the ones we don't see in our own testing. Where to report: start right here in this thread. It keeps everything visible to the community and lets others on the same setup jump in. If something turns out to be a reproducible bug, we'll move it to a GitHub issue on the repo so the team can track it to a fix. Release notes and migration guide: https://github.com/vatesfr/xenorchestra-csi-driver/releases/tag/v0.4.0