@psafont thats good to know the system will prevent you from uploading the same ISO. Since my latest testing i cant seeem to get XO-CE to show the incorrect file name .img of the iso that was uploaded. But know @plaidypus is not alone in this as I have seen it myself and that is why you will see most of the iso in the picture have a date just a few days prior to this recent testing. I manually deleted the iso that were .img and manually uploaded the ISOs again.

@olivierlambert Beyond 'Did you try rebooting it?', I think 'Have you updated to the latest version?' is the second hard and fast rule all IT people should follow. I suspected the problem was that I was a few releases behind, so I ran an update. It brought the software to 5.109, though I didn't check the blog release page to confirm if I was in fact on the latest. I can finally sleep well tonight!

@umbradark Nope but we'll be happy to do so.

Thanks @abudef !

@olivierlambert the answer seems to be "no timeout" as of now the task has been stuck like this for 30+ hours. only way i can make it go away is to restart the XO Proxy. something i can't do right now due to another task running a huge delta mirror sync.

@Mathieu Thanks to your help, we are deploying a patch with config update and control over document and assertion signatures https://github.com/vatesfr/xen-orchestra/pull/9093 pierrebrunet289 opened this pull request in vatesfr/xen-orchestra open fix(plugin/auth-saml): add default config in SAML #9093

Excellent news! Thanks for the feedback

@bleader Hi, After a restart of the entire host, port 6640 is now listed when I trigger ss. But, unfortunatly, tunnels are not working, every VM on this host loose connection to other in the same sdn network. Exemple with an ping between two hosts : 2025-10-09T12:22:54.781Z|00026|tunnel(handler1)|WARN|receive tunnel port not found (arp,tun_id=0x1f1,tun_src=192.0.0.1,tun_dst=192.0.0.3,tun_ipv6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_tos=0,tun_ttl=64,tun_erspan_ver=0,gtpu_flags=0,gtpu_msgtype=0,tun_flags=key,in_port=33,vlan_tci=0x0000,dl_src=56:30:10:5c:4d:ad,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.10.10,arp_tpa=192.168.10.20,arp_op=1,arp_sha=56:30:10:5c:4d:ad,arp_tha=00:00:00:00:00:00) 2025-10-09T12:22:54.781Z|00027|ofproto_dpif_upcall(handler1)|INFO|Dropped 61 log messages in last 59 seconds (most recently, 1 seconds ago) due to excessive rate 2025-10-09T12:22:54.781Z|00028|ofproto_dpif_upcall(handler1)|INFO|received packet on unassociated datapath port 33 If I migrate the VM on the third host to another, network came back. This is very strange, because the network I've choose to test it is one of firt of all created, not last one, so it have worked before, and not now. I don't understand why and what to do...

I created a GitHub issue to track this feature request: https://github.com/vatesfr/terraform-provider-xenorchestra/issues/378 gCyrille created this issue in vatesfr/terraform-provider-xenorchestra open CPU topology (sockets/cores) for new VMs deployed via Terraform #378

@Pilow said in "ACLs" and "VM creator" options on the VM´s Advanced tab: @panzersrmm I tried to snapshot and revert on a VM with Resource set + ACLs and they did not disappear... ? [image: 1759935440961-b316a971-e2cf-4843-9d05-a96b2299d12a-image.png] @Pilow Yes, yours were kept because you didn't modify them manually. My test case was: Set ACLs + VM creator for a working VM Make a snapshot of this VM Change various VM advanced properties including ACLs + VM creator (simulate evolution of VM) Revert the VM to that snapshot state Check if the set properties were restored: all were restored except ACLs I was wrong about VM creator. That is indeed restored, but ACLs isn't. @olivierlambert Thank you for the explanation. I wasn't trying to judge, just to understand how it actually works.

@dinhngtu That got my fresh install to boot as well. Thank you!

@andriy.sultanov said in "Block migraton" option on the VM´s Advanced tab: @panzersrmm @panzersrmm said in "Block migraton" option on the VM´s Advanced tab: Hi! Is there a VM parameter that saves this "Block migration" UI button? I wasn't able to identify which one it is with command: xe vm-param-list uuid=<VMuuid> Thank you! How do you mean? Is the XO option not persistent? XO sets these parameters: # xe vm-list uuid=$UUID params=blocked-operations blocked-operations (MRW) : pool_migrate: true; migrate_send: true Which you can set like this yourself: # xe vm-param-set uuid=$UUID blocked-operations:migrate_send=true # xe vm-param-set uuid=$UUID blocked-operations:pool_migrate=true @andriy.sultanov Thank you for your answer! That's what I was looking for. I was looking directly at the VM parameters, with xe vm-param-list uuid=$UUID and I was directly searching for "blocked_migration". Now I know what to look for. @olivierlambert Thank you for pinging the appropriate team for the answer.

Hi, As the message said, please reach out to us, you can use the contact form https://vates.tech/contact We'll be happy to discuss and assist in your evaluation

Since I'm not used to using git, I was running a few tests on my "test" host. I had made a change in my "one line commando" My memory is not in best shape so I forgot the change and ran it in my update. Now It's sorted out and ran a new update and voila

@psafont Sounds good on point #1. On point #2 I agree LLA shouldn't be the primary management IPv6 address on the interface, but you could run into trouble by not having a LLA address assigned at all. All of the IPv6 standards assume a LLA is assigned to an interface running IPv6 for things like NDP or RA to work ergo mysterious things could break as a result of an LLA address not being assigned. Just spitballing here, but if you're concerned that only an LLA would be assigned to an interface then perhaps there could be logic to disable IPv6 for said management interface if no non-LLA address is assigned, or IPv4 could be preferred if only LLA addresses as assigned?

Edited your post to use the right Markdown syntax, otherwise it's a pain to read

Hi, To start, it's good to read: https://docs.vates.tech/security/ Especially https://docs.vates.tech/security/#contact--disclosure Then, I can answer here directly: we are not affected since Redis is only listening locally, therefore it's not exposed outside XO. There's nothing interesting to do with that CVE, because in order to use it, you already must be a privileged user.

100% agree, "stacked" tags are great. @lsouai-vates can you pass the word because I think XO 6 team isn't aware of those "stacked" tags in XO 5