@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

Hi, Likely a bug in our graph library or XAPI, if you have it, I'm curious to see if you see the same issue on XO Lite

Yes, if you removed the master without tell it to transition the master role to another machine, you have to promote manually your current slave if your "old master" isn't there anymore

@Jonathon @olivierlambert If it is not being blocked, then it may be their efforts to prevent node saturation by moving from node to node. What plan are you on, is it the free one? If so then this movement will occur more frequently as they move from node to node roughly around every 5-10 minutes. So will experience this loss (timeout) of connection on a regular basis! With a paid plan its much less frequently, also the Cloudflare ZT support team with detailed logs may be able to aid in stabilising connectivity. https://community.cloudflare.com/t/my-remote-users-drop-at-least-5-times-a-day-randomly/474817 https://community.cloudflare.com/t/cloudflare-ssh-proxy-dropping-connections/397306 Their minimum paid plan with 100% uptime and SLA is the "Pay-as-you-go" plan. So if your going to be carrying out actions in XOA regularly over a remote connection, which need to have a long timeout then a paid plan would pay for itself.

weird. got it.

@olivierlambert Sorry. I was working some other stuff, so I haven't had a chance to look. And I don't know if I will have time until next weekend. Thank you for checking up, though. I will post when I have an update on the situation.

@kevdog You can force a host to be ejected even if the host is not reachable any longer from the pool master using: xe host-forget uuid=UUID If there is any issue because VMs are thought to be running still on that host, you may need to do a power state reset on such before you can get rid of that host. See if that works for you.