And we are blown away by our wonderful community! Thank you very much, and happy to help you!

There are just many locations for the logs and the seem to have to be handled quite different: Audit-Logs: Can be exported and so can be sent to syslog, but: I did not find a way to do that efficient, as "xo-cli get-Records" seems not to be able to use filters like "after/before". Pool-Log: Is only visible in the GUI. Did not find a way to send it to syslog, or to export it periodically. XOA-Log: /var/log/syslog can be exported, but is using quite nasty "multi-line-logs". Task-Log: As Audit-Logs: Can be fetched by: "xo-cli rest get tasks", but did not get filters working, yet. It would be perfect to have options to send directly to syslog, but a workaround through a periodically running script could be good, too.

I wonder when XenCenter stores this name since there's no XAPI field for it

Nice! Let us know if you want it to be added on the REST API

If this specific VM is causing issue, you can fallback on Clonezilla or something similar

Different brand? Can be the controller too. But reading what I'm seeing on the screen, it's very likely to be a disk issue.

@itiojoe You're welcome ! Have fun with Xen Orchestra !

@olivierlambert Bug has been filed. https://github.com/vatesfr/xen-orchestra/issues/7193 ajpri created this issue in vatesfr/xen-orchestra closed Can't Remove PIF #7193

Hi! The first reflex when you have an issue is to check: Pre-requisites: https://xen-orchestra.com/docs/installation.html#packages-and-pre-requisites Being up to date In your case, it was 1 Note: Node 20 compatibility will come soon but it doesn't mean 1 & 2 should be done before anything else Also, nice catch @Danp

Issue is now fixed on master branch. A patch release for XOA Latest will come at some point

Okay, glad to know it works! Good luck for the rest of your operations!

OK then I will wait. The icons are not an important feature for survival anyway.

FWIW, I just ran into this same issue with Node 20.9.0, which is the current LTS version. Reverting to Node 18.18.2 resolved the issue for me.

Yes, it will be a LOT easier to find it in XO 6

It's like your XOA wasn't up to date

So that makes sense then Closing here

Correct - through the CLI one could see that the old VM that had been migrated from Host1 to Host2 was still showing under Host1, whilst the migrated copy was showing as running on Host2. Once the Host1 remnant of the migration was removed that cleared things and XO correctly reported the VM as running on Host2 with its disks attached. TLDR - There were no other conflicts beyond what appeared through XO to be the only version sitting halted on Host1, but through the CLI one could see the halted copy on Host1 and the running copy on Host2. Somehow the running version did not show in XO until the remnant was removed. Thanks for your help @olivierlambert

@Darkbeldin I started another topic because it seemed like there were some differences in my issue than was described here. However there are significant similarities too. https://xcp-ng.org/forum/topic/7881/xo-user-authentication-excessive-and-unknown-tasks I'm having this on xo-server 5.124.0, xo-client is 5.126.0 with a fully patched XCP-ng 8.2.1. You mention this being fixed recently. Any idea which specific version this was patched on and how it compares to the versions I listed?

It's a projection based on the task progress, not a truth. If it takes very long to start (eg first few %), the projection will be wrong