For the record, since upgrading to 5.63 the issue hasn't re-occurred at all.

I don't get it, what's the connection with the current discussion?

Before applying the patch, in a new pool (during the CH8 update process to XCP8), when moving any VM to the updated host I received the error below.

After installing the patch on the master host and restarting the toolstack on the host master and the source host, we no longer notice error, with the migrate process successfully completing.

The error condition was the failed shutdown of the VM in the live migrate process. So I think the patch made available actually solves the problem in question. (for VMs with and without network interfaces)

Nov 30 12:54:48 SECH82 xapi: [error|SECH82|946189 ||backtrace] Async.VM.pool_migrate R:29b4b31d74de failed with exception Server_error(INTERNAL_ERROR, [ xenopsd internal error: Device_common.QMP_Error(135, "{\"error\":{\"class\":\"GenericError\",\"desc\":\"Unable to open /dev/fdset/0: No such file or directory\",\"data\":{}},\"id\":\"qmp-000029-135\"}") ]) Nov 30 12:54:48 SECH82 xapi: [error|SECH82|946189 ||backtrace] Raised Server_error(INTERNAL_ERROR, [ xenopsd internal error: Device_common.QMP_Error(135, "{\"error\":{\"class\":\"GenericError\",\"desc\":\"Unable to open /dev/fdset/0: No such file or directory\",\"data\":{}},\"id\":\"qmp-000029-135\"}") ]) Nov 30 12:54:48 SECH82 xapi: [error|SECH82|946189 ||backtrace] 1/1 xapi @ SECH82 Raised at file (Thread 946189 has no backtrace table. Was with_backtraces called?, line 0 Nov 30 12:54:48 SECH82 xapi: [error|SECH82|946189 ||backtrace]

https://github.com/vatesfr/xen-orchestra/issues/4467

pdonias created this issue in vatesfr/xen-orchestra closed Hide legacy backup menu entry #4467

Don't be sorry: there is some tool designed to do something, and other for other things. You don't expect that your everyday car will fly. It would be the same thing if XO was working in the browser only. We made that choice (to have a server part) because we knew we'll push for features requiring to run 24/7.

XOA supports CH 8.0, what's your error? XOA use another mechanism because CBT isn't really worth it (we use delta VHD instead, which is compatible even with XS Free)

If I understand correctly, the "ISO" you are asking for is for building drivers. I don't intend on creating a specific ISO just for that. Everything is available in yum repositories to build drivers (usually you just need make, gcc and kernel-devel), and there's also a docker image at https://github.com/xcp-ng/xcp-ng-build-env

I do prefer Olivier's suggestion, though: going through support, because drivers built for one user through support are made available to other users through our repositories.

@bnrstnr said in Storage Link:

Can you explain better exactly what you're trying to do?

Only for easy mapping of a disk to storage directly to a virtual server.
Thus Avoiding the need for iSCSI configuration within the Guest VM.

I Know the appeal today is no longer available... My question is whether anyone knows if it is still possible to perform via CLI or if there are plans to be implemented again.

No, because those logs are useful in case of problem (to find a potential bug). However, they are garbage collected automatically (the oldest ones) after a while.