jr-m4

@poddingue
Our HA-pool is a 3 host system, yes.

I'll add a note about our plans to go paid in that feedback-item. Thanks for the tip.
In the meantime, I'm testing and reporting as much as I can. In order to hopefully help the product be better for all.

Cheers!

@poddingue

Huh.. Good catch.
I set all of the VMs to restart, and now it does make maintenance mode possible, on the host.

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.

Perhaps there could be a way to assign a global/pool-wide HA-plan along with enabling HA alltogether?

Update: Shining light on that there is already a feedback-item, wishing for this kind of mass-operation for HA.
https://feedback.vates.tech/posts/45/bulk-operation-for-setting-vm-ha-option

Doing some more testing, where I wished to place one Host in maintenance mode. I was then met with HOST_NOT_ENOUGH_FREE_MEMORY.
The pool is a 3 host pool in HA, with load balancing enabled.

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.

What I had to do, was manually disable load balancing. And manually migrate VMs to the two other hosts, to distribute them. This worked.

What I expected to have happened:
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.

Commit: 2f846
XCP-NG: Fully updated as of writing

host.setMaintenanceMode
{
  "id": "<obfuscated>",
  "maintenance": true
}
{
  "code": "HOST_NOT_ENOUGH_FREE_MEMORY",
  "params": [
    "OpaqueRef:<obfuscated>"
  ],
  "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:<obfuscated>",
    "progress": 1,
    "type": "<none/>",
    "result": "",
    "error_info": [
      "HOST_NOT_ENOUGH_FREE_MEMORY",
      "OpaqueRef:<obfuscated>"
    ],
    "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:<obfuscated>)",
  "name": "XapiError",
  "stack": "XapiError: HOST_NOT_ENOUGH_FREE_MEMORY(OpaqueRef:<obfuscated>)
    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 (<anonymous>)
    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)"
}

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)

@poddingue

Thanks for taking a look.

Yes it is this part that tells me that it should start the VM automatically once the import has completed.
"After the transfer, the VM on XCP-ng side is started:"
Followed by, "This process is fully automated, without any human intervention after it starts on step 1."

https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/

But my findings/experience is that the VM does not start once the import/transfer has completed.

So either the docs are wrong. Or the function is not behaving as intended. I'm acctually fine either way. As long as I know what to expect. However, I would like to have it auto-start the VMs after transfer completion. Which would make the procedure "Fully automated".

Update:
Am I assuming correctly that "the XO V2V guide says to start the VM yourself once the migration is complete " you're reffering to, is part of the "test migration"-procedure? Not the acctual production mgiration?
Because:

"Final migration
Run the production migration
When you're ready for the final migration:

Shut down the source VM completely.
Start the V2V migration in Xen Orchestra with the Stop source option enabled.
This ensures the final sync happens while the VM is powered off, and prevents any inconsistencies."

In my mind doesn't state that the VM should be started manually post-transfer.

Great thanks in advance for discussing!
Cheers!

Further testing:

Testing with newer commit: 27882fb1dcd24fc5257835e60b3fa1002e4e885c
Still same results.

I've tried with both original VM powered on, and off. No change in end-result. The VM imports properly. But it doesn't power on automatically as expected after the import has completed. Manual powering on is then needed to be performed.

I'm only importing 1 VM at a time. And I've tried with the field Number of VMs to import in parallel both at the default value of 2 and reduced to 1. No change in behaviour from this either.

@tjkreidl

Thanks for your long post. I hope someone else will find it helpfull.
However, I am pretty much reporting that the autostart after importing with V2V might be buggy at best or broken at worst. Not the autostart after boot part (that works).

Cheers

@dinhngtu said:

Hello,

Windows only supports adding CPUs but not removing them.

This is a Windows limitation.

I'm not surprised by that limitation. Thanks for confirming anyway.

Cheers!

I'm at the moment doing alot of test with V2V (applause on getting rid of the vddk-dependency btw )

However, what I'm noticing is that the migrated VMs don't automatically start when the import has completed. This is contrary to current documentation.

Is this a potential bug? Or am I missing something obvious?

PS: The imports are all sucessfull. It's just the auto-start part that I'm noticing doesn't work.

Cheers!

Commit: dc573

Template used for testig is: Rocky Linux 9

I'm doing a couple of tests to trying to figure out quirks and behaviours from XCP-ng side, for a future production (licensed) setup.

So I tried to see what would happen if I would play with the number of vCPUs on two guests.
TL;DR: Reducing vCPUs on Windows requires reboot.

On Windows Guest:
OS: Windows Server 25
Guest Agent: 9.2.385.0
Increasing the number of vCPUs up to the max value, is done live and works well. But reducing the vCPUs requires a reboot.

However. On a Rocky Linux 10 installation. The reducing works immediately live and online as expected.

This might very well be a limitation of how Windows does things internally. But I thought it interesting enouch to report about anyway.

@JorisK said:

fix/update-transfer-size-calculation

I can confirm that XO6 now shows the same transfer sizes as XO5. Lovely