Posts made by henri9813 | XCP-ng and XO forum

henri9813

Thanks for your investigation, this confirm my guess.

I removed them manually to reclaim disk space.

But in my opinion, the health should detect "useless directory". in the vdi directories. But this is "required" only if the backup metadata was clean without the directory cleaned.

henri9813

Hello,

I have a backup plan which backups all vms with a tag: backup=yes ( exemple ) to a NFS remote.

The backups appear in the Health section, and then, i click on delete ( to cleanup the space ).

But ... nothing is deleted on the remote.

the only things i can found a list of directory to clean in the xen-orchestra logs

xen-orchestra  | 2026-09-26T15:32:05.190Z xo:backup-archive INFO you could delete orphan VDI directory {
xen-orchestra  |   path: '/xo-vm-backups/e92f154d-0b9d-2c69-fb04-d8bf58b6e8f0/vdis/756c7d04-3b06-4b5d-b66d-b6ef6c4d53b1/e9228694-76f1-43e9-9e2e-18a1c91f5a01'
xen-orchestra  | }

Why XO doesn't clean the data in the remote ?

And now, how to make it clean ? ( i upgraded the xo, and then, i don't have my previous logs which mentions the list of directory to clean )

Thanks !

henri9813

Hello @Maelstrom96.

This should be possible in the future version of XCP-NG built on top of alma 9

henri9813

Hello @poddingue , you right.

Yes i saw this article, but it was unrelated to my issue.

I agree your guess.

How can i mark the topic as Solved ?

henri9813

Hello.

Problem Solved.

My case:

i have a pool of many hypervisors with only local storage, no shared SR ( yes it's not recommanded, i stopped doing this and i'm currently migrating everything to pool with Shared storage ).

Yesterday, i removed two hosts ( host 3 & host 4 ) whith local storages SR attached ( LVM ).

In XCP-NG, i "forgot" Host 3 & host 4, the hosts from the pool, but it doesn't forge the associated SR !

But Live migrating a VM from host 1 to host 2 ( of the same pool ) bot with local SR, FAIL because there is no SR plugin attached of Local Storage 4 ( hosts 4 ) neither Local storage 3 ( host 3 ).

So, i also forget theses 2 SRs and now it's ok.

i don't understand why SR not connected to anyone can prevent migration about vm from other to other sr.

henri9813

Hello.

I have this error while trying to migrate VM from a host to another host. ( same versions ).

Jul 10 10:58:06 server xapi: [debug||3148384 ||storage_utils] Got failure: checking for redirect, call was: -> SR.scan({sr:S(a2e6300f-10f2-ec61-bcfb-6a1d62a00bff);dbg:S(Async.VM.migrate_send R:afa4f5b49fd9)}), results.contents: ["No_storage_plugin_for_sr","a2e6300f-10f2-ec61-bcfb-6a1d62a00bff"]
Jul 10 10:58:06 server xapi: [debug||3148384 ||storage_utils] Not a redirect: -> SR.scan({sr:S(a2e6300f-10f2-ec61-bcfb-6a1d62a00bff);dbg:S(Async.VM.migrate_send R:afa4f5b49fd9)})
Jul 10 10:58:06 server xapi: [error||3148384 ||storage_interface] Storage_error ([S(No_storage_plugin_for_sr);S(a2e6300f-10f2-ec61-bcfb-6a1d62a00bff)]) (File "ocaml/xapi-idl/storage/storage_interface.ml", line 451, characters 49-56)
Jul 10 10:58:06 server xapi: [error||3148384 ||storage_migrate] Storage_migrate.MigrateLocal.prepare Caught error Storage_error ([S(No_storage_plugin_for_sr);S(a2e6300f-10f2-ec61-bcfb-6a1d62a00bff)]) while preparing for SXM
Jul 10 10:58:06 server xapi: [error||3148384 ||storage_migrate] Caught Storage_error ([S(Migration_preparation_failure);S(Storage_error ([S(No_storage_plugin_for_sr);S(a2e6300f-10f2-ec61-bcfb-6a1d62a00bff)]))]) during SXM:
Jul 10 10:58:06 server xapi: [error||3148384 ||task_server] Task 3 failed; Storage_error ([S(Internal_error);S(Storage_error ([S(Migration_preparation_failure);S(Storage_error ([S(No_storage_plugin_for_sr);S(a2e6300f-10f2-ec61-bcfb-6a1d62a00bff)]))]))])
Jul 10 10:58:06 server xapi: [debug||3148384 ||storage] TASK.signal 3 = ["Failed",["Internal_error","Storage_error ([S(Migration_preparation_failure);S(Storage_error ([S(No_storage_plugin_for_sr);S(a2e6300f-10f2-ec61-bcfb-6a1d62a00bff)]))])"]]

Do you know what No_storage_plugin_for_sr mean ?

It's a simple local storage

henri9813

Hello there

I start to use slowly XO6 since many features was added.

But i observe this:

I have a VM with 3 backups jobs associated:

02/07/2026 - 8H47: Success
02/07/2026 - 8H48: Fail
02/07/2026 - 8H54: Success

But in the UI, i see this:

The jobs should be order from the "most recent" to "older one" ( or vice versa, i don"t have opinion on it ).

But showing the fail as the first make us thinks that the last jobs fail, that's not the case.

I should have:

Thank you

henri9813

Hello,

All is in the title

Is this normal ?

Thanks !

henri9813

Hello,

Thanks for all !

henri9813

Hello,

To gave more details abouit my case:

XCPNG: 8.3.0
CPU: AMD EPYC 4464P 12-Core Processor
Kernel: 6.12.0-211.18.1.el10_2.x86_64

henri9813

Hello,

When i boot a Rocky Linux 10 with the latest kernel, it's very slow on cpu XXX spinlock event irq.

Someone have the same issue ?

Thanks !

henri9813

@gregoire said:

@olivierlambert I added this feature request in the backlog regarding RPU improvements.

Hello,

Thanks all !

Totally agree with @poddingue , be able to exclude VM which has:

PCI attached devices
Local storage ( maybe ? )

Could be a great option !

henri9813

Hello @McHenry .

Yes but no, once the snapshot is exported, the previous one must be cleaned on local.

Best regards,

henri9813

Hello,

I see also this behavior which is "new" since few weeks.

Previously, when a backup start:

it stake a snapshot ( if there another one before, it delete it ).
it upload the snapshot as a backup
it coalesce the backup on the remote.
end of the game.

Now, the old snapshots are not deleted anymore which can lead easily to some disk full.

Even with a retention of 1, the problem is present.

I observe this only in Backup job, not DR/CR job.

I just updated my XO to latest version, i will see if the issue is fixed.

henri9813

Hello,

In the post about XCP-NG 9.0, there was a discussion about Storage Domain Virtual machines, as i understood, the project was abandonned, but the concept is still doable without this implementation.

https://xcp-ng.org/forum/post/102311

On each of my hosts, i have a VM dedicated for ceph which mount the PCI devices ( NVME disks ).

Everything works like a charm !

But the RPU is not available due to the VMS which have PCI attached resources.

Is it possible to exclude VMS from RPU and make it shutdown before the upgrade ?

something like you done to exclude Security warning about old windows guest tools.

This would be very great

henri9813

Hello @nikade.

I agree but this is my case.

Try to migrate a running VM: error 500
Try to migrate an halted VM: error 500.
Warm migrate: It's okay.

I don't understand myself the difference except it doesn't transfer the "VM" but recreate the VM and import the VDI, ( so , the same things ), but there may be a light difference. I don't know how the "warm migration" works under the hood

henri9813

Hello,

I was able to perform "Warm" migrate from either the slave or the master.

Yes the master was rebooted.

@henri9813 Did you reboot the master after it was updated? If yes, I think you should be able to migrate back the VM's to the master, and then continue patcting the rest of the hosts.

No, i would migrate back vm from MASTER (updated ) to slave ( not updated ), but wasn't working.

Only warm migrations works.

henri9813

Hello, @Danp

My pool is in upgrade, not all nodes are updated.

I evacuate the master hosts's vms to the slave node except 3-4 vms which are "very not important and can be shut for few minutes
I upgrade the master node with success
I WANT to move all vms to the master, but it deosn't have enought disk space, so i tried the following:
a. Migrate the very not important VM to the slave node ( not updated ) to have enought space to move the "important" vms.
b. Move vms of the updated master to ANOTHER pool.

I tried both:

VM running
VM halted

Thanks !

henri9813

I have an updated pool.

I'm evacuating an host for update to another pool.

But the operation fail, and remains in the XO tasks

VM metadata import (on new-hypervisor) 0%

and in the VM.migrate api call detail.

vm.migrate
{
  "vm": "30bb4942-c7fd-a3b3-2690-ae6152d272c5",
  "mapVifsNetworks": {
    "7e1ad49f-d4df-d9d7-2a74-0d00486ae5ff": "b3204067-a3fd-bd19-7214-7856e637d076"
  },
  "migrationNetwork": "e31e7aea-37de-2819-83fe-01bd33509855",
  "sr": "3070cc36-b869-a51f-38ee-bd5de5e4cb6c",
  "targetHost": "36a07da2-7493-454d-836d-df8ada5b958f"
}
{
  "code": "INTERNAL_ERROR",
  "params": [
    "Http_client.Http_error(\"500\", \"{ frame = false; method = GET; uri = /export_metadata?export_snapshots=true&ref=OpaqueRef:75e166f7-5056-a662-f7ff-25c09aee5bec; query = [  ]; content_length = [  ]; transfer encoding = ; version = 1.0; cookie = [ (value filtered) ]; task = ; subtask_of = OpaqueRef:9976b5f2-3381-e79e-a6dd-0c7a20621501; content-type = ; host = ; user_agent = xapi/25.33; }\")"
  ],
  "task": {
    "uuid": "9c87e615-5dca-c714-0c55-5da571ad8fa5",
    "name_label": "Async.VM.assert_can_migrate",
    "name_description": "",
    "allowed_operations": [],
    "current_operations": {},
    "created": "20260131T08:16:14Z",
    "finished": "20260131T08:16:14Z",
    "status": "failure",
    "resident_on": "OpaqueRef:37858c1b-fa8c-5733-ed66-dcd4fc7ae88c",
    "progress": 1,
    "type": "<none/>",
    "result": "",
    "error_info": [
      "INTERNAL_ERROR",
      "Http_client.Http_error(\"500\", \"{ frame = false; method = GET; uri = /export_metadata?export_snapshots=true&ref=OpaqueRef:75e166f7-5056-a662-f7ff-25c09aee5bec; query = [  ]; content_length = [  ]; transfer encoding = ; version = 1.0; cookie = [ (value filtered) ]; task = ; subtask_of = OpaqueRef:9976b5f2-3381-e79e-a6dd-0c7a20621501; content-type = ; host = ; user_agent = xapi/25.33; }\")"
    ],
    "other_config": {},
    "subtask_of": "OpaqueRef:NULL",
    "subtasks": [],
    "backtrace": "(((process xapi)(filename ocaml/libs/http-lib/http_client.ml)(line 215))((process xapi)(filename ocaml/libs/http-lib/http_client.ml)(line 228))((process xapi)(filename ocaml/libs/http-lib/xmlrpc_client.ml)(line 375))((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/importexport.ml)(line 313))((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/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/xapi_vm_migrate.ml)(line 1920))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 2551))((process xapi)(filename ocaml/xapi/rbac.ml)(line 229))((process xapi)(filename ocaml/xapi/rbac.ml)(line 239))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 78)))"
  },
  "message": "INTERNAL_ERROR(Http_client.Http_error(\"500\", \"{ frame = false; method = GET; uri = /export_metadata?export_snapshots=true&ref=OpaqueRef:75e166f7-5056-a662-f7ff-25c09aee5bec; query = [  ]; content_length = [  ]; transfer encoding = ; version = 1.0; cookie = [ (value filtered) ]; task = ; subtask_of = OpaqueRef:9976b5f2-3381-e79e-a6dd-0c7a20621501; content-type = ; host = ; user_agent = xapi/25.33; }\"))",
  "name": "XapiError",
  "stack": "XapiError: INTERNAL_ERROR(Http_client.Http_error(\"500\", \"{ frame = false; method = GET; uri = /export_metadata?export_snapshots=true&ref=OpaqueRef:75e166f7-5056-a662-f7ff-25c09aee5bec; query = [  ]; content_length = [  ]; transfer encoding = ; version = 1.0; cookie = [ (value filtered) ]; task = ; subtask_of = OpaqueRef:9976b5f2-3381-e79e-a6dd-0c7a20621501; content-type = ; host = ; user_agent = xapi/25.33; }\"))
    at XapiError.wrap (file:///etc/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12)
    at default (file:///etc/xen-orchestra/packages/xen-api/_getTaskResult.mjs:13:29)
    at Xapi._addRecordToCache (file:///etc/xen-orchestra/packages/xen-api/index.mjs:1078:24)
    at file:///etc/xen-orchestra/packages/xen-api/index.mjs:1112:14
    at Array.forEach (<anonymous>)
    at Xapi._processEvents (file:///etc/xen-orchestra/packages/xen-api/index.mjs:1102:12)
    at Xapi._watchEvents (file:///etc/xen-orchestra/packages/xen-api/index.mjs:1275:14)"
}

My XO is up to date.

I already update the master, i'm processing the slave.

But neither the master ( updated ) nor the slave ( not updated ) can migrate VM to an updated pool.

Do you have an idea ?

henri9813

Hello @florent ,

You mean, "check" right ? because if it's doesn't check, the job is finished before the merge and the merge run in background in xen orchestra.

Best regards,