<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Enable Maintenance Mode = Host Not Enough Memory]]></title><description><![CDATA[<p dir="auto">Doing some more testing, where I wished to place one Host in maintenance mode. I was then met with <code>HOST_NOT_ENOUGH_FREE_MEMORY</code>.<br />
The pool is a 3 host pool in HA, with load balancing enabled.</p>
<p dir="auto">My guess is that when trying to enable Maintenance mode. It tries to migrate ALL VMs on that host, to ONE single Host on the receiving end. And then it exhausts the amount of available memory.</p>
<p dir="auto">What I had to do, was manually disable load balancing. And manually migrate VMs to the two other hosts, to distribute them. This worked.</p>
<p dir="auto">What I expected to have happened:<br />
The evacuation of the host going into Maintenance mode, would be distributing the VMs in a smarter fashion. So that their workload would fit in the pooled resources available.</p>
<p dir="auto">Commit: 2f846<br />
XCP-NG: Fully updated as of writing</p>
<pre><code>host.setMaintenanceMode
{
  "id": "&lt;obfuscated&gt;",
  "maintenance": true
}
{
  "code": "HOST_NOT_ENOUGH_FREE_MEMORY",
  "params": [
    "OpaqueRef:&lt;obfuscated&gt;"
  ],
  "task": {
    "uuid": "c3a83a2d-003d-ac0f-48b8-79a905c9e557",
    "name_label": "Async.host.evacuate",
    "name_description": "",
    "allowed_operations": [],
    "current_operations": {},
    "created": "20260929T07:46:40Z",
    "finished": "20260929T07:46:40Z",
    "status": "failure",
    "resident_on": "OpaqueRef:&lt;obfuscated&gt;",
    "progress": 1,
    "type": "&lt;none/&gt;",
    "result": "",
    "error_info": [
      "HOST_NOT_ENOUGH_FREE_MEMORY",
      "OpaqueRef:&lt;obfuscated&gt;"
    ],
    "other_config": {},
    "subtask_of": "OpaqueRef:NULL",
    "subtasks": [],
    "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_host.ml)(line 629))((process xapi)(filename hashtbl.ml)(line 159))((process xapi)(filename hashtbl.ml)(line 165))((process xapi)(filename hashtbl.ml)(line 170))((process xapi)(filename ocaml/xapi/xapi_host.ml)(line 625))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/rbac.ml)(line 228))((process xapi)(filename ocaml/xapi/rbac.ml)(line 238))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 78)))"
  },
  "message": "HOST_NOT_ENOUGH_FREE_MEMORY(OpaqueRef:&lt;obfuscated&gt;)",
  "name": "XapiError",
  "stack": "XapiError: HOST_NOT_ENOUGH_FREE_MEMORY(OpaqueRef:&lt;obfuscated&gt;)
    at XapiError.wrap (file:///opt/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12)
    at default (file:///opt/xen-orchestra/packages/xen-api/_getTaskResult.mjs:13:29)
    at Xapi._addRecordToCache (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1358:24)
    at file:///opt/xen-orchestra/packages/xen-api/index.mjs:1392:14
    at Array.forEach (&lt;anonymous&gt;)
    at Xapi._processEvents (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1382:12)
    at Xapi._watchEvents (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1589:14)"
}
</code></pre>
<p dir="auto">Update: Edited title, since it would suggest Load Balancing was the problem. It isn't. It's the assignment of migration target(s) that is the issue (imho)</p>
]]></description><link>https://xcp-ng.org/forum/topic/12498/enable-maintenance-mode-host-not-enough-memory</link><generator>RSS for Node</generator><lastBuildDate>Tue, 29 Sep 2026 09:04:14 GMT</lastBuildDate><atom:link href="https://xcp-ng.org/forum/topic/12498.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 29 Sep 2026 07:53:25 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Enable Maintenance Mode = Host Not Enough Memory on Tue, 29 Sep 2026 08:39:16 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/poddingue" aria-label="Profile: poddingue">@<bdi>poddingue</bdi></a></p>
<p dir="auto">Huh.. Good catch.<br />
I set all of the VMs to  <code>restart</code>, and now it does make maintenance mode possible, on the host.</p>
<p dir="auto">However, when we go into licensed/paid production (soon tm). It would be an absolute nightmare to try and find one VM that might not be on the right HA-plan... And it does kind of feel that Maintenance-mode should be compatible with whatever HA-plan is chosen regardless.</p>
<p dir="auto">Perhaps there could be a way to assign a global/pool-wide HA-plan along with enabling HA alltogether?</p>
]]></description><link>https://xcp-ng.org/forum/post/108741</link><guid isPermaLink="true">https://xcp-ng.org/forum/post/108741</guid><dc:creator><![CDATA[jr-m4]]></dc:creator><pubDate>Tue, 29 Sep 2026 08:39:16 GMT</pubDate></item><item><title><![CDATA[Reply to Enable Maintenance Mode = Host Not Enough Memory on Tue, 29 Sep 2026 08:26:33 GMT]]></title><description><![CDATA[<p dir="auto">Your thread looks a lot like <a href="https://xcp-ng.org/forum/topic/12321">https://xcp-ng.org/forum/topic/12321</a>. Same error, same call, HA enabled there too. Olivier's answer on that one was that VMs whose HA restart priority isn't Restart aren't protected, so they never get a real evacuation plan.<br />
His two workarounds were setting those VMs to Restart, or turning HA off for the maintenance window.</p>
<p dir="auto">It doesn't land for everyone, though. On <a href="https://xcp-ng.org/forum/topic/12348">https://xcp-ng.org/forum/topic/12348</a> <a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/majorp93" aria-label="Profile: MajorP93">@<bdi>MajorP93</bdi></a> fixed his by moving every VM from best-effort to restart, and <a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/acebmxer" aria-label="Profile: acebmxer">@<bdi>acebmxer</bdi></a> tried the same thing and got <code>HA_OPERATION_WOULD_BREAK_FAILOVER_PLAN</code> instead. Same change, opposite outcome. <img src="https://xcp-ng.org/forum/assets/plugins/nodebb-plugin-emoji/emoji/android/1f937.png?v=2d1219998ab" class="not-responsive emoji emoji-android emoji--shrug" style="height:23px;width:auto;vertical-align:middle" title=":shrug:" alt="🤷" /></p>
<p dir="auto">So, what are your VMs set to, restart or best-effort? That would tell us whether you're looking at the same thing or something else entirely.</p>
<p dir="auto">Upstream there are two PRs off the back of that discussion. <a href="https://github.com/xapi-project/xen-api/pull/7145" target="_blank" rel="noopener noreferrer nofollow ugc">7145</a> merged on 8 July and only makes the error message clearer. <a href="https://github.com/xapi-project/xen-api/pull/7146" target="_blank" rel="noopener noreferrer nofollow ugc">7146</a> is the one that changes the evacuation behaviour itself, and it's still open. So if it is the same problem, I don't think there's anything you can pull down yet.</p>
]]></description><link>https://xcp-ng.org/forum/post/108740</link><guid isPermaLink="true">https://xcp-ng.org/forum/post/108740</guid><dc:creator><![CDATA[poddingue]]></dc:creator><pubDate>Tue, 29 Sep 2026 08:26:33 GMT</pubDate></item></channel></rss>