Yes, there's a possible weird combo between XOSTOR and HA in some situations. Let me add @ronan-a or @dthenot in the loop. It's likely that XOA disconnection is just a visible symptom of something else. It's not ultra trivial to reproduce though.

@olivierlambert Thank you. I thought maybe I was losing my mind/eye sight, especially after reading that google search indicating there was a start button in 6.

Excellent news

No idea if anyone have "fixed" anything No, the XO commit 5fcb6 hang for ~3 min at reboot today. edit: I disabled the sceduled reboot yesterday.

@MathieuRA I disabled Traefik and reverted to my old XO config (port 443, ssl encryption, http to https redirection), rebuild the docker container using your branch and tested: it is working fine on my end now Thank you very much! I did not expect this to get fixed so fast!

It won't disappear tomorrow, but I'd like to phase it out sooner than later (before 2027? who knows)

Ok I've figured out root cause. My config override has only one option: ignoreVmSnapshotResources = true And I had to change it with adding [selfService] on a line below Also I found out that override config for XO5 interface needs to have absolute paths to xo-web and @XenOrchestra in it. With relative paths it didn't work.

I would like to suggest to configure a remote syslog server. it centralizes all the log s and give you full control over the retention. It would also avoid situation where a disk full would impact your logging as well XCP-ng or XOA host operations. For your XCP-NG host go to you POOl, select Advanced tab and configure the Remote syslog host section to point to your syslog server. For XOA, you can follow the instruction here : https://docs.xen-orchestra.com/backups#send-xo-logs-to-an-external-syslog-server

@ideal perhaps you could use advantage of dynamic memory https://docs.xcp-ng.org/vms/#dynamic-memory to oversubscribe memory and have all 4 VMs up at once... or reduce the allocated memory of your VMs, you seem to have a pretty big VM in terms of memory in comparison to the 2 others on your screenshot

@olivierlambert Just to add another weird case of this situation I tell you my SAML-auth-adventures. I have just migrated a week ago from XOCE to XOA paid support this week and all the process was fine except the auth with the saml plugin. The commit I had in XOCE was [XO 5d92f - Master 3f604]. I compiled it the first week of this november so it wasn't very outdated. We use the MSEntraID SAML authentication and it was working fine in XOCE since at least one year ago. Mi process was like this: First, I installed XOA and imported the configuration from my old XOCE. Everything was fine and all was imported succesfully (backups, users, acls, etc.), including my plugin configurations. Note that I reused the https server certificate/private key and used the same IP and the same DNS (beacuse I turned off my XOCE before starting XOA). Everything was working fine except the saml auth plugin. I had the same "Internal server error" problem. I looked at the xo-server logs and the error was "invalid document signature" so, as Olivier said, we changed the configuration in MSEntraID to set the "Sign SAML response and assertion" on. Once we changed the configuration I thought the plugin would work again, but surprisingly not. If I try again SAML validation i still got the "Internal server error". When i checked again the xo-server logs I saw ahother exception, this time with the error "SAML assertion audience mismatch" and a reference to the issuer configuration of the plugin. The exact error I got from xo-server logs using "journalctl -u xo-server -f -n 50" was: "xoa xo-server[2370]: Error: SAML assertion audience mismatch. Expected: <id-of-MSEntraID-xo-validation> Received: spn:<id-of-MSEntraID-xo-validation>"I didn't understand this, because the configuration was exactly the same as I had in XOCE. In fact, I turned off XOA and turned on again XOCE just to test the plugin. The result was that in XOCE the plugin worked well. After many tries and some time of impostor syndrome we found the solution: I don't know why, but in XOCE compiled at the beginning of november you have to configure the issuer field of the plugin with the <id-of-MSEntraID-xo-validation> (8digit-4digit-4digit-4digit-12digit). Instead, in XOA deployed also this november, you have to set the issuer field to you XOA URL: https://<xo.company.net>/ I hope this will help, because it was a pain in the neck for us this week. BTW: @olivierlambert this "Internal server error" coming from an uncatched exception in the plugin was not very descriptive. Even a generic try-catch block just to show in the web interface the error would help... P.D.: I'm from Spain, so I do my best with my english P.D. 2: Great job with all the Vates virtualization stack! You are the best! Dani

We'd recently got a relevant experience regarding this weird renaming to uuids. We had one orchestra managing one pool. ISOs were in an ISO SR, with an nfs4 serving it underneath. All fine till then. We added one second pool to the orchestra. Just a single host by itself. One of the very next days we discovered that all names in the ISO SR had been replaced by uuids. Removing/readding the sr to the new pool helped temporarily. Usual names appeared again. But after a few more days, again uuids. Where uuids were appearing, we could not select anything from the dropdown list in the console's cdrom. The list per pool was unpopulated. We tried separate the shares by offering the new pool an nfs4 share from the NAS, actually sharing the same source dir. It did mount but now there was a uuid uniq constraint that was violated, so we could not see no files at all in this new SR. It would not be an illogical thought to have an 'iso sr' attached once to the orchestra and be offered by the orchestra to all managed pools, without uuids, without uniqs etc. There seems to be an unnecessary complication here I think.

I haven't had too much difficulty hitting the esc key in time to get into the EFI config. Click the start VM button, quickly click away from the display area and click in the display area, then toggle the esc key until I see it take effect. I know I have a couple running at 1920x1080, but that's actually kind of a pain. I only did that to try and get a larger RDP window, RDP may be limited by the original "monitor" resolution, but this might also be fixed in later updates. This one VM has been up for a few years. (edit, yes this has been changed, VMs with a 4x3 monitor now RDP is whatever I have set).

Hi, I just responded to your ticket with the steps to update XOA to match your new license. Regards, Dan

@WorkAccount1000 Prior to myself finding that option in the config file use to run this command that worked as well.. cd /opt/xo/xo-web sudo yarn run turbo run build --filter @xen-orchestra/web

@bogikornel said in Cannot migrate a vmdisk: @ashinobi Known issue ... https://xcp-ng.org/forum/topic/11538/failed-to-migrate-vdi-two-local-sr/5?_=1763186433370 Thank you so much for letting me know. I'll follow your post so I can update that if they need more info on what is happening.

@rizaemet-0 I've also enabled SAML and the login interface is a little bit odd, not only the remember me button but also the capitalization of SAML which is lowercase. It is a cosmetic issue, but still an issue.

@olivierlambert Yes I previously was. now back on VHD. This was in my home lab, not work enviorment.

To anyone still having this issue or finding this thread when searching online: "How to clone a VM between hosts in Xen Orchestra" or similar... The key piece of information missing from all these answers is that you must first connect both hosts (XCP-ng) servers to the same Xen Orchestra instance before you can clone (copy (export/import)) a VM from one host to another while using the Xen Orchestra GUI. Note that as mentioned in the first reply that this is only one solution, given both hosts can see each other over the network. You can also manually export and import the VM as an image file to your local PC's storage if needed. To do this, first navigate to "Settings->Servers" and configure/connect the destination host alongside the existing host so you end up with two hosts connected to the same Xen Orchestra. Note that Xen Orchestra can display information and manage multiple hosts if required (does not have to be tied to a single XCP-ng instance). Then navigate back to "Home->VMs" and you should now see all VMs listed for both hosts in the same list. From here you can select the VM to clone and from the copy dialog menu when you select a "SR" you should now be able to select between both host's disks (Local Storage or Pools) to copy the VM onto. Note that this command will spin up two separate tasks: an export and import task simultaneously on each host to complete the copy (sort of streaming it at the same time). Also don't forget to first shutdown the VM first before you copy it so you do not risk losing/corrupting any live data while it is cloning. Hope this helps everyone.