@AtaxyaNetwork @Pilow @bvitnik Ok, knowing that the p2 partition was likely an old backup was exactly the breadcrumb that I needed. I confirmed via chroot and xsconsole that p2 was xcp-ng v8.2.1, and that p1 was v8.3. Then I was able to check the initrd files there. Namely I needed to see the updated dates and the kernel version. Thankfully, I saw initrd files on the backup that were the correct kernel and hadn't been disturbed. I then just cloned the initrd files from the backup partition to the p1 partition and BOOM. We booted right up. Much appreciated for the assistance, everyone. I'll still need to figure out why my disks are disconnecting, but that will be another post for another day.

@acebmxer Great. These are some YAML basics. You should read more about it . Following AI instructions without understanding is not going to take you far.

With new created backup jobs, everything works. Clearly there are some hickups in the GUI when switching between backup modes. Not sure if it is worth fixing with XO6 coming up, though.

It's been 2y since it's out and it works perfectly. To me, it's entirely production grade, even already far better than the XenServer ones. We mostly need time to create a 1.0, it's only a question of prioritization on our end. I will make sure @gregoire monitor the situation in here.

@dnordmann said in V2V - Stops at 99%: @florent Ticket#7747444 and I just opened another ticket for the other client that is having the same issue. Ticket#7748053. Support tunnels should be open for both clients. Thanks! I deployed the patch on the new client, if it's ok I will do the second one after

@Forza Cancelling a backup run is also on our roadmap ,as soon as we have done reworking the tasks to use xo-task on the full chain, and not an hybrid of various iteration of the tasks objects better tracking of the backup run is also on our roadmap , this is also linked to the task changes plus are some issues with the size on the remote before being able to do this In any case, both are on our backlog

@florent Unfortunately it is not working. Yesterday when I checked it was actually backing up a VM which had only 2 disks and by mistake I thought it was one of the VMs with a lot of disks attached to it. Sorry for the confusion. It still looks like this [image: 1764063276716-1a1b9b32-52bb-44e2-9c1f-9427e3925e14-grafik.png] Even though I added to my config file at /etc/xo-server/config.toml: #===================================================================== # Configuration for backups [backups] diskPerVmConcurrency = 2 Other settings I defined in /etc/xo-server/config.toml are working just fine. E.g. setting HTTP to HTTPS redirection, SSL certificate or similar. So I think Xen Orchestra (XO from sources) reads my config file. It appears that the backup option "diskPerVmConcurrency" does not have any effect at all. No matter in what file I set it. Is this setting working for anyone else?

@hoehnp we're aiming at sharing a very first public version before end of year, but don't hope for it to be anything complete or stable

There are no other jobs. I've now spun up a completely separate, fresh install of XCP-ng 8.3 to test the symptoms mentioned in the OP. Steps taken Installed XCP-ng 8.3 Text console over SSH xe host-disable xe host-evacuate (not needed yet of course since it's a brand-new install) yum update Reboot Text console over SSH again Created local ISO SR xe sr-create name-label="Local ISO" type=iso device-config:location=/opt/var/iso_repository device-config:legacy_mode=true content-type=iso cd /opt/var/iso_repository wget # ISO for Ubuntu Server xe sr-scan uuid=07dcbf24-761d-1332-9cd3-d7d67de1aa22 XO Lite New VM Booted from ISO, installed Server Text console to VM over SSH apt update/upgrade installed xe-guest-utilities Installed XO from source (ronivay script) XO Import ISO for Ubuntu Mate New VM Booted from ISO, installed Mate apt update/upgrade xe-guest-utilities New CR backup job Nightly VMs: 1 (Mate) Retention: 15 Full: every 7 Exact same behaviour. After first (full) CR job run, additional (incremental) CR job runs results in one more 'unhealthy VDI'. I've engaged in no other shenanigans. Plain vanilla XCP-ng and XO. There are only two VMs on this host, the XO from source VM, and a desktop OS VM which is the only target of the CR job. There are zero exceptions in SMlog. What do you need to see?

@olivierlambert said in LargeBlockSR for 4KiB blocksize disks: I don't see any reason it couldn't, but I prefer @dthenot to answer I'm able to create and use two local SRs using type largeblock, but upon restarting the host, one of them is always disconnected and I'm not sure how to reconnect it. I'm guessing it has something to do with the loop setup. Thoughts? pbd.connect { "id": "8d8b8a97-314f-8e07-56a5-170e9ac37973" } { "code": "SR_BACKEND_FAILURE_202", "params": [ "", "General backend error [opterr=Command ['vgs', '--noheadings', '-o', 'vg_name,devices', 'XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553', '--config', 'devices{scan=[\"/dev/\"]}'] failed (Volume group \"XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553\" not found Cannot process volume group XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553): Input/output error]", "" ], "task": { "uuid": "bd8f1c89-e04c-adbb-381c-d8cc8434ac51", "name_label": "Async.PBD.plug", "name_description": "", "allowed_operations": [], "current_operations": {}, "created": "20251124T14:58:07Z", "finished": "20251124T14:58:07Z", "status": "failure", "resident_on": "OpaqueRef:644ca431-7524-53a1-a152-33704b6cbbaf", "progress": 1, "type": "<none/>", "result": "", "error_info": [ "SR_BACKEND_FAILURE_202", "", "General backend error [opterr=Command ['vgs', '--noheadings', '-o', 'vg_name,devices', 'XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553', '--config', 'devices{scan=[\"/dev/\"]}'] failed (Volume group \"XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553\" not found Cannot process volume group XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553): Input/output error]", "" ], "other_config": {}, "subtask_of": "OpaqueRef:NULL", "subtasks": [], "backtrace": "(((process xapi)(filename lib/backtrace.ml)(line 210))((process xapi)(filename ocaml/xapi/storage_utils.ml)(line 145))((process xapi)(filename ocaml/xapi/xapi_pbd.ml)(line 191))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 141))((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/message_forwarding.ml)(line 5776))((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": "SR_BACKEND_FAILURE_202(, General backend error [opterr=Command ['vgs', '--noheadings', '-o', 'vg_name,devices', 'XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553', '--config', 'devices{scan=[\"/dev/\"]}'] failed (Volume group \"XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553\" not found Cannot process volume group XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553): Input/output error], )", "name": "XapiError", "stack": "XapiError: SR_BACKEND_FAILURE_202(, General backend error [opterr=Command ['vgs', '--noheadings', '-o', 'vg_name,devices', 'XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553', '--config', 'devices{scan=[\"/dev/\"]}'] failed (Volume group \"XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553\" not found Cannot process volume group XSLocalLargeBlock-83636851-e064-9d16-8356-0aca60f70553): Input/output error], ) at Function.wrap (file:///opt/xo/xo-builds/xen-orchestra-202510021218/packages/xen-api/_XapiError.mjs:16:12) at default (file:///opt/xo/xo-builds/xen-orchestra-202510021218/packages/xen-api/_getTaskResult.mjs:13:29) at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202510021218/packages/xen-api/index.mjs:1073:24) at file:///opt/xo/xo-builds/xen-orchestra-202510021218/packages/xen-api/index.mjs:1107:14 at Array.forEach (<anonymous>) at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202510021218/packages/xen-api/index.mjs:1097:12) at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202510021218/packages/xen-api/index.mjs:1270:14)" }