michmoor0725

@olivierlambert
Thanks for being so transparent about this. I suspect just updating that error message should be helpful enough. I was really struggling yesterday as I couldn’t figure out why my test plan was failing.
Your suggestions did indeed work. In my case just disabling HA briefly did the trick

Environment

• XCP-ng version: 8.3 (latest)
• Xen Orchestra (XO): Build 202606261855
• Pool topology: 2-node pool ("Olympus")
  • Host A (master, Zeus): 128 GB RAM, 7 VMs running (~34 GB allocated)
  • Host B (slave, Hera): 64 GB RAM, 4 VMs running (~32 GB allocated)
• HA: Enabled, ha-host-failures-to-tolerate = 0, ha-overcommitted = false
• Storage: Shared NFS SRs (all VMs on shared storage — no local-SR VMs)

What I'm trying to do

Test planned maintenance / HA evacuation: reboot Host B (Hera) via Xen Orchestra, expecting its running VMs to live-migrate to Host A (Zeus) automatically.

---

What happens

The host.restart call from XO (with suspendResidentVms: false, bypassCurrentVmCheck: false) fails immediately with:

HOST_NOT_ENOUGH_FREE_MEMORY(OpaqueRef:<vm-ref>)

Full task error:

  {
    "error_info": [
      "HOST_NOT_ENOUGH_FREE_MEMORY",
      "OpaqueRef:<vm-opaque-ref>"
    ],
    "name": "XapiError",
    "message": "HOST_NOT_ENOUGH_FREE_MEMORY(OpaqueRef:<vm-opaque-ref>)",
    "stack": "XapiError: HOST_NOT_ENOUGH_FREE_MEMORY(OpaqueRef:<vm-opaque-ref>)\n    at XapiError.wrap (file:///opt/xo/xo-builds/.../packages/xen-api/_XapiError.mjs:16:12)\n    at default 
  (file:///opt/xo/xo-builds/.../packages/xen-api/_getTaskResult.mjs:13:29)\n    ..."
  }

Backtrace points to ocaml/xapi/xapi_host.ml:629 inside Async.host.evacuate.

The same error is produced when running xe host-evacuate directly on the pool master:

Not enough server memory is available to perform this operation.
needed: <vm-uuid> (<VM name>)
available: <unknown>

Note the available: <unknown> — XCP-ng cannot determine the available memory on the destination host.

Actual memory figures from xe host-list params=memory-free,memory-total,memory-overhead:

┌────────────────────────┬───────────┬──────────┬──────────┐
│          Host          │ Total RAM │ Free RAM │ Overhead │
├────────────────────────┼───────────┼──────────┼──────────┤
│ Zeus (destination)     │ 128 GB    │ 84.7 GB  │ 1.58 GB  │
├────────────────────────┼───────────┼──────────┼──────────┤
│ Hera (being evacuated) │ 64 GB     │ 26.5 GB  │ 0.93 GB  │
└────────────────────────┴───────────┴──────────┴──────────┘

VMs on Hera that need to migrate:

┌───────┬──────────────────┬─────────────────┐
│  VM   │ RAM (static-max) │ memory-overhead │
├───────┼──────────────────┼─────────────────┤
│ VM-1  │ 12 GB            │ 106 MB          │
├───────┼──────────────────┼─────────────────┤
│ VM-2  │ 8 GB             │ 74 MB           │
├───────┼──────────────────┼─────────────────┤
│ VM-3  │ 8 GB             │ 74 MB           │
├───────┼──────────────────┼─────────────────┤
│ VM-4  │ 4 GB             │ 36 MB           │
├───────┼──────────────────┼─────────────────┤
│ Total │ 32 GB            │ 290 MB          │
└───────┴──────────────────┴─────────────────┘

Zeus has 84.7 GB free. The VMs need ~32.3 GB (RAM + overhead). There is 52 GB of headroom. The error should not occur.

Any help appreciated — this makes planned host maintenance require manual CLI steps every time, which defeats the purpose of the evacuate-on-reboot workflow.

This community is amazing Great job all around!

@Tackyone
You solution fixed it for me. Lost a few days of logs as well and i am on the latest commit of the XO community edition.

Theres some bug with syslog clear but your fix works great.

@olivierlambert

Nevermind. Second time the upgrade went smoothly.

HolySmokes.......XO Lites is niiiiiice.

Great job all around

@olivierlambert
Now that im back on 8.2 where i can look in the filesystem to review the logs?

@olivierlambert I can use the 8.3 ISO to reload 8.2 ?

System: Dell R620
XCP NG:8.2

Got in through idrac and attempted to upgrade to 8.3. After a few minutes i received the following error

I went ahead and rebooted the system as that was the only option but not i get to the grub menu.

Cany anyone provide any pointers as to how i can rescue this server?

@olivierlambert Im confident it will all come together in the future!

@Danp
You are correct. That was not intuitive or discoverable at all for me but I do stand corrected in my comments.

Thank you @Danp