@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?

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.

@tc-atwork thanks for post, i wasnt able to get xo6 setup as i havent had time to play with it. I look forward to when it released. For now I just keep using xo-lite to open the console window.

@dfrizon said in How to protect a VM and Disks from accidental exclusion: @olivierlambert The idea is to block the VM and exclusion disks even by root itself, and make it possible only via command line in the console. That's why I started the post by mentioning the command... We dream of the day when MFA authentication will be required to delete a VM... How would you prevent the root account from taking action..... that is the absolute opposite permission set of root, as if there is an account with even more permissions than root. You can use permission sets and move your team who are deleting powered off VM's that are protected from accidental deletion into a group that doesn't have the permission to delete VMs, at the same time, remove their permissions from deleting items from your SR. I think that would solve your problem, and doesn't cause any logical permission issues like above.

@olivierlambert Here's the new model. We've tried a few combinations and I think with TrueNAS shared storage this will now work well. [image: 1759787234216-f78178c0-3330-4233-8f9b-debc3c61a3e9-image.png]

@lsouai-vates

@gduperrey The thing is, the i40e driver works fine for me with the regular kernel. I was hoping to try kernel-alt to see whether it would resolve my erroneous CPU thermal shutdown issues (to narrow down whether it's a kernel issue or not), but then I ran into the driver issue. I can try that alt driver, though, and see if it works with kernel-alt for me.

@Forza Good point. I need to apply the latest patches anyway, so I'll be rebooting the pool later today anyway.

@ThisGuy_420 Great! We'll try to get those tools available more broadly and finally get a 1.0 officially, this is taking too much time while they are perfectly working. Pinging @Team-OS-Platform-Release

@acebmxer said in Veeam backup with XCP NG: and when not accidentally routing the backups... save 6 min.. [image: 1759373010653-screenshot-2025-10-01-224148.png] host [image: 1759373021630-screenshot-2025-10-01-224223.png] Amazing, that's really impressive. Backups has always taken a long time with XOA once you start to backup a lot of VM's so I hope this will improve the overall backup performance

@olivierlambert Ideally XCP-ng (xapi) could add this to a queue, and wait for some time before cancelling the task because it took too long. This also needs some kind of feedback that can be given to the user / client, which I think currently is quite undercooked (how to report is waiting on other migrations to the same host when a client asks?). For the time I think XO being aware that it can retry the operation would be simpler, especially because it already has code to do it for other operations

@Pilow I thought restarting tool stack affected both host? Either way did try that but on host 1 originally. So i restarted on host 2 (where problem is). still no locked. I rebooted host 2 and that seem to do the trick. Took a few min for garbage collection to complete. All clean now. Thanks.

I believe this was a bug that was fixed in later versions: https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX678047

@MajorP93 stress of VM migration XD good luck with your V2Vs !

Maybe a bad command that overwrote the file, anyway glad you managed to make it work!

@farokh one backup job should leave one snapshot. this is the way. to differentiate from previous backup the data to be put in the delta, it has to refer to this snapshot. delete it and you get a full backup ongoing. if you have two snaps on your VM, either you have a manual one, or you have multiple backup jobs backuping this VM (check the backup tab of the VM ?)

The unusual one happened to occur on a Master (though not all Masters have this reverse ordering).

@vmpr hello, to be able to address the problem more clearly can you give me the version of your XO please? and if you are on stable or latest? XO v5.111.0 has been publicly released in latest channel yesterday.

Hi, @samuelolavo can you run the following command on the dom0 and paste its output please: grep -A5 "'XCP-ng'" /etc/grub.cfg Then also run lspci -vvv xe pci-list xl pci-assignable-list