We could probably make the doc even more precise. Adding @thomas-dkmt in the loop for that.

Yes but why it works with some and not others. I suspect the firmware version in the NIC itself.

I also added windows build so that people can help with testing also on windows. It's a static build, no need for installer, just single zipped .exe file. No dependencies.

@majorp93 I've updated and added a node.js-installation to the role. Targeting the LTS-24 version. I hope you find it to your liking.

If I remember some previous discussions, EVE-ng uses some features that doesn't work in nested mode with Xen.

@wlp94114 said in Intel x710-t2l Problems: The x710 series has a reputation for being picky about driver and nvram versions. Out of curiosity, is there anything reported by the linux driver that would allow make the situation obvious?

@irtaza9 it scans all the VDI's on the SR to see if something has changed, if there's a need for coalesce and so on. I dont think it will be a big issue if you increase the auto-scan-interval value to lets say 5 minutes (300 seconds), but do remember, that everything regarding the VDI's on the SR will take up to 5 minutes to update, as well as triggering coalesce after removing snapshots.

@Pilow Does disk show up after you do the snapshot? If it is able to do the snapshot there is a high chance it can boot up. So try booting up (and check for disk) and shut it down and do the snapshot at that time if the disk show up. It helps to boot up on the old v5 commit and check from that side too if you have both copy before the commit update. Yep I can confirm that snapshot doesn't always work. But using the older v5 that used to work before the update does get it showing up on the newer v5 commit if I go through whole snapshot, revert, etc. one of those case work.

@andSmv I definitely think it would be nice with support even though i repurposed my M2 Coral for other uses. But one thing to keep in mind regarding resources is that the product would appear to be heading to https://killedbygoogle.com coral.ai redirects to their new NPU offering and no updates have been made from google to the driver since 2022... Mouser still has plenty of stock though. Frigate.nvr which is one of the popular uses for the Coral do not recommend it for new installs either.

We are not energy efficiency experts, while EasyVirt people are. I think they already have some stuff and it might be just a matter of plumbing.

Thank you! So in this case, if better option for me to join the hosts to existing pool and then shutdown VMs and start it on host with older CPUs. Thank you again!

@florent, I had to do the same for Xen Orchestra Community Edition. In my case, config.toml already contained the [authentication] section, so adding a separate config.tokenValidity.toml file did not work. Instead, I had to modify the existing config.toml located at /opt/xo/xo-server. In my opinion, it is best to keep defaultTokenValidity set to 30 days as a fallback in case no value is specified. You can then simply increase maxTokenValidity to the duration you prefer. [authentication] defaultTokenValidity = '30 days' # default value of 0.5 years # comment out and increase to 5 years #maxTokenValidity = ' 0.5 year' maxTokenValidity = '5 year'

@bvitnik Thanks for giving more details. I will give a try with each of them (netplan, ..etc)

Hi @Kptainflintt, I don't think this is related to XO6, but probably to this PR: https://github.com/vatesfr/xen-orchestra/pull/9231 VDIs with snapshot_of: <something> are now recognized as snapshots spacotte-vates opened this pull request in vatesfr/xen-orchestra closed fix(xo-server): improve handling of xapi snapshots #9231

@acebmxer It's not pretty, but its failsafe. The proceedure looked like this in our case: Disable HA in the "old pool" Put a host in the "old pool" into maintenance mode Reinstall that host and connect it to XOA and then patch it Create a "new pool" from that host Create a new LUN or NFS share in the SAN for "new pool" and attach it to "new pool" Live migrate VM's over from "old pool" to "new pool" Once you've freed up another host you repeate step 2 and 3 and then join that host to "new pool". It is important that you patch it before joining it to the pool, that is done by going to Settings -> Servers in XOA and connect to it manually. And then just continue untill you're done. Live migration is pretty reliable now days, so this works pretty good and since we had 10G network its not taking as long as it used to do with 1G network. We did this after a major incident on our primary production site where 2 out of 4 hosts in a pool "suddenly" lost their NIC's after updating them. Since then we never updated the pools again. Standalone hosts are fine tho, they never did this. Luckily we had 2 other pools where we could migrate the VM's to, but we couldn't realy trust the updating after that.

@olivierlambert thank for that. Just to be clear the vm was not runing but shut down if that makes a difference. @ph7 Both firewalls are Unifi Enterprise fortress gateways. - https://techspecs.ui.com/unifi/cloud-gateways/efg?subcategory=all-cloud-gateways Both sites are setup with Site Magic VPN. So should be full 1.1gbps if accurate. [image: 1767705099263-screenshot-2026-01-06-081123.png]

@TeddyAstie Sure thing: xl_dmesg.txt Dom0_dmesg.txt DomU_dmesg.txt

@DaleDibbadel Are you running XOA or XO from the sources? Are you up-to-date?

Resolved by rebuild, and doing VM backup and metadata to trunas dataset.... Start Backup earlier. Be better then me