@olivierlambert after fiddeling around with almost every advice including dpkg-reconfigure grub-pc and to re-enable OS Proper (which aparently was disabled between 20.04 and 22.04) the one thing that worked for me was to purge grub* and reinstall it.
So i still have no idear what was going on, but i have my VM booting now on 22.04 
Thanks for all the idears.
As this is just a test restore of my live system i have a snapshot pre-release upgrade. Can i do something else besides using grub-install and update-grub ? I have found this while looking for the error: https://askubuntu.com/questions/1404066/executing-grub2-command-nativedisk-before-boot-for-huge-disks
But to me its unclear why its should be necessary to mess with the disk module all of a sudden.
I converted to PVHVM after using grub-install /dev/xvda successfully on Ubuntu 20.04 LTS and it boots just fine.
Now if i do-release-upgrade to 22.04 LTS the VM hangs on GRUB "grub_disk_native_sectors".
Am i missing something ?
I am not sure why exactly, probably because the inital Install is quite old, i think its coming from 14.04. or 16. I will try to install grub on xvda and convert it. I was not aware that PV would become "suddenly" an issue 
Coming from 20.04 LTS i updated my VM to 22.04 LTS and now i cant start it anymore:
vm.start
{
"id": "9a540088-556f-30ba-434f-317697ca6532",
"bypassMacAddressesCheck": false,
"force": false
}
{
"code": "INTERNAL_ERROR",
"params": [
"xenopsd internal error: (Failure
\"Error from xenguesthelper: xenguest: xc_dom_parse_image: [2] panic: xc_dom_core.c:693: xc_dom_find_loader: no loader found\")"
],
"call": {
"method": "VM.start",
"params": [
"OpaqueRef:c817057a-3994-4447-8ed1-8322610029c9",
false,
false
]
},
"message": "INTERNAL_ERROR(xenopsd internal error: (Failure
\"Error from xenguesthelper: xenguest: xc_dom_parse_image: [2] panic: xc_dom_core.c:693: xc_dom_find_loader: no loader found\"))",
"name": "XapiError",
"stack": "XapiError: INTERNAL_ERROR(xenopsd internal error: (Failure
\"Error from xenguesthelper: xenguest: xc_dom_parse_image: [2] panic: xc_dom_core.c:693: xc_dom_find_loader: no loader found\"))
at Function.wrap (/opt/xen-orchestra/packages/xen-api/src/_XapiError.js:16:12)
at /opt/xen-orchestra/packages/xen-api/src/transports/json-rpc.js:35:21
at runNextTicks (node:internal/process/task_queues:60:5)
at processImmediate (node:internal/timers:447:9)
at process.callbackTrampoline (node:internal/async_hooks:130:17)"
}
Maybe because this VM was created as 18.04 some years ago? How can i fix that
@planedrop are you using LVM for that or how are u doing that? I never bothered with the problem because i dont have enough local space for 8TB disk snapshots anyways.
Thanks for the heads up. A [NOSNAP] Feature sounds like a good idea though
@olivierlambert maybe i missunderstood things, the RAW Disk from my XO VM is the 7TB data disk "[NOBAK] xoa_backup_hdd".
The system disk is "xoa_sda" is not RAW.
So i thought excluding the disk with "[NOBAK]" would make me able to snapshot the VM (system disk). So whenever you have attached a RAW device makes you unable to snapshot the VM.
Detaching it, taking a snapshot and reattaching it would work however?
@olivierlambert Okay but obviously i can create snapshots on the RAW SR (here OPensense in the screenshot above). So this is a should but bould sometiomes does work situation ?-)
@olivierlambert Yes i think it is, if i remember correct that was the only way to add +4TB drives ?
I just tested to do a snapshot from another VM on that disk, that works.
@olivierlambert Well its virtual disk is located on a local attached 8TB Disk .....
@olivierlambert
Its running on a Local attached 8TB Disk thats also used to Store the Backups
I was trying to take a Snapshot from my XOA (Source) VM before updating it but aparently i cant:
vm.snapshot
{
"id": "4ac34777-312e-cb6e-67a0-ccc34a71f8e1"
}
{
"code": "UNIMPLEMENTED_IN_SM_BACKEND",
"params": [
"OpaqueRef:662bcb78-4ffa-4c26-8d82-c5197d7c7e07"
],
"task": {
"uuid": "a24d6e0f-04cf-039d-b0bb-6a53589f9874",
"name_label": "Async.VM.snapshot",
"name_description": "",
"allowed_operations": [],
"current_operations": {},
"created": "20230331T07:07:23Z",
"finished": "20230331T07:07:24Z",
"status": "failure",
"resident_on": "OpaqueRef:7a2e10b8-677f-4c65-95cd-b8393884450b",
"progress": 1,
"type": "<none/>",
"result": "",
"error_info": [
"UNIMPLEMENTED_IN_SM_BACKEND",
"OpaqueRef:662bcb78-4ffa-4c26-8d82-c5197d7c7e07"
],
"other_config": {},
"subtask_of": "OpaqueRef:NULL",
"subtasks": [
"OpaqueRef:b2436483-c1ee-447c-8016-636a52c61528"
],
"backtrace": "(((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 80))((process xapi)(filename list.ml)(line 110))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 122))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 35))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 130))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 171))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 209))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 220))((process xapi)(filename list.ml)(line 121))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 222))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 442))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 35))((process xapi)(filename ocaml/xapi/xapi_vm_snapshot.ml)(line 33))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 131))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/xapi/rbac.ml)(line 233))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 104)))"
},
"message": "UNIMPLEMENTED_IN_SM_BACKEND(OpaqueRef:662bcb78-4ffa-4c26-8d82-c5197d7c7e07)",
"name": "XapiError",
"stack": "XapiError: UNIMPLEMENTED_IN_SM_BACKEND(OpaqueRef:662bcb78-4ffa-4c26-8d82-c5197d7c7e07)
at Function.wrap (/opt/xen-orchestra/packages/xen-api/src/_XapiError.js:16:12)
at _default (/opt/xen-orchestra/packages/xen-api/src/_getTaskResult.js:11:29)
at Xapi._addRecordToCache (/opt/xen-orchestra/packages/xen-api/src/index.js:984:37)
at forEach (/opt/xen-orchestra/packages/xen-api/src/index.js:1018:14)
at Array.forEach (<anonymous>)
at Xapi._processEvents (/opt/xen-orchestra/packages/xen-api/src/index.js:1008:12)
at Xapi._watchEvents (/opt/xen-orchestra/packages/xen-api/src/index.js:1181:14)
at runNextTicks (node:internal/process/task_queues:60:5)
at processImmediate (node:internal/timers:447:9)
at process.callbackTrampoline (node:internal/async_hooks:130:17)"
}
Every other VM on that host i can snapshot just fine.
I even tried shutting it down and then taking a snapshot with the same result.
8.2.1 Host is Up2Date
@olivierlambert i have created config.httpInactivityTimeout.toml in /opt/xen-orchestra/packages/xo-server with the content from above. Not sure how i can check if thats actually set.
BTW: this is not a CR Backup Problem, i also dont see Tasks running for my "normal" Backup Job. I cant check "how far" the actual Backup runs and if that differs.
@Darkbeldin there is enough space for the snapshot and on the remote. How can i investigate the root rause further?
2022-07-04T10_53_26.656Z - backup NG.txt
I have the same problem now, did this ever get resolved?
From source (today):
Xen Orchestra, commit 34c84
xo-server 5.98.0
xo-web 5.99.0
Hmm it sounded like SR_BACKEND_FAILURE_79 would only mean one thing as its the same error when you try to create a disk > 2TB. But i know nothing about all that.
"stack": "XapiError: SR_BACKEND_FAILURE_79(, VDI Invalid size [opterr=VDI size must be between 1 MB and 2088960 MB], )
@olivierlambert yeah i found that later.
The XO message could be more informative though
Oh i might have found the issue here
Aug 24 13:13:16 xcp-ng SM: [6430] Raising exception [79, VDI Invalid size [opterr=VDI size must be between 1 MB and 2088960 MB]]
So i cant migrate anything with disks larger 2TB or is there a workaround?