@Thiago_FS_Dantas hi, did you check NESTED VIRTUALISATION in the advanced tab of your VM ? [image: 1767872120619-3f93e473-b1eb-4a92-aca7-a684ff9a23ae-112fdd1c-a3bf-4636-81a9-f24aecd818f7.png]

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

Hi! Thanks for the feedback. Can you be more specific? This might be helpful if others would have the same issue Thanks!

Hello @olivierlambert, @bastien-nollet, Hello Everyone !! I used vhd-cli with its new arguments and it worked ok. vhd-cli check --chain 'file:///run/xo-server/mounts/11934fec-f3a1-4f7f-a78d-00eeb1b39654?useVhdDirectory=true&encryptionKey=%22O1xt1ZTRE%5Qq%3X%3D1NZ%26%3ZZQo8%2DD%29s5xt%3OOko%22' 'xo-vm-backups/abc3e130-923e-619e-4fdc-59bcda088586/vdis/cecc4489-722a-4f79-b5e6-c050f63f2761/d489173c-028a-46f0-b712-f4a7c5594c8f/20260108T160552Z.alias.vhd' ok: xo-vm-backups/abc3e130-923e-619e-4fdc-59bcda088586/vdis/cecc4489-722a-4f79-b5e6-c050f63f2761/d489173c-028a-46f0-b712-f4a7c5594c8f/20260108T160552Z.alias.vhd But I discovered that using vhd-cli in this way only checks the physical structure of the alias.vhd file. It doesn't check the integrity of the blocks or the total number of blocks to detect a missing block. (It doesn't work like it does with huge monolithic .vhd files, where it detects errors with the slightest modification.) So I opted to split the solution: I check the integrity of the filesystem where the files are stored (using btrfs scrub). I verify that the number of blocks written in the backup is correct (that no blocks are missing). I verify that the written blocks haven't been modified since they were written. For point 2, I found (AI) that I could use "vhd-cli info" to find out the total number of blocks in the backup (I don't have much information about it), but when I run it, I get the following error. I suspect it doesn't work with (Encrypt all new data sent to this remote): vhd-cli info --chain 'file:///run/xo-server/mounts/11934fec-f3a1-4f7f-a78d-00eeb1b39654?useVhdDirectory=true&encryptionKey=%22O1xt1ZTRE%5Qq%3X%3D1NZ%26%3ZZQo8%2DD%29s5xt%3OOko%22' 'xo-vm-backups/abc3e130-923e-619e-4fdc-59bcda088586/vdis/cecc4489-722a-4f79-b5e 6-c050f63f2761/d489173c-028a-46f0-b712-f4a7c5594c8f/20260108T160552Z.alias.vhd' ✖ Unhandled remote type Error: Unhandled remote type at getHandler (/usr/lib/node_modules/vhd-cli/node_modules/@xen-orchestra/fs/dist/index.js:48:11) at getSyncedHandler (/usr/lib/node_modules/vhd-cli/node_modules/@xen-orchestra/fs/dist/index.js:54:19) at Object.info (/usr/lib/node_modules/vhd-cli/commands/info.js:98:24) at Object.runCommand (/usr/lib/node_modules/vhd-cli/index.js:32:13) at /usr/lib/node_modules/vhd-cli/node_modules/exec-promise/index.js:57:13 at new Promise (<anonymous>) at execPromise (/usr/lib/node_modules/vhd-cli/node_modules/exec-promise/index.js:56:10) at Object.<anonymous> (/usr/lib/node_modules/vhd-cli/index.js:41:1) at Module._compile (node:internal/modules/cjs/loader:1706:14) at Object..js (node:internal/modules/cjs/loader:1839:10) Could you please help me with this? I'm not sure if I'm on the right track. Perhaps there are other ways I'm missing.

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

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

@dalem That looks awesome ! Glad to see nix/nixos getting more and more adoption. It must have been a pain to build the pkgs, thanks a lot for working on this. I'll give it a try when I manage to free some time. Have you considered upstreaming the module/pkgs to nixpkgs or is this too much work ? I have not contributed there yet so I don't know if it would get merged as is.

Same behavior: Tools from the ubuntu repo 7.20 don't work on Ubuntu 24.04 (but they work on ubuntu 22.04. But manually installing the tools from the cdrom (version 7.30) work fine

Hi according to gh, it looks like there is traction on this feature: https://github.com/xcp-ng/xcp-ng-release/pull/53#discussion_r2642865515 So it might be merged soon... rzr opened this pull request in xcp-ng/xcp-ng-release closed s/c/e/profile.d/history.sh: Add timestamps to history #53

Also works with alt driver (broadcom-bnxt-en-alt-1.10.3_231.0.162.0-1.xcpng8.2.x86_64) in 8.2.1: # yum install broadcom-bnxt-en-alt # reboot # modinfo bnxt_en filename: /lib/modules/4.19.0+1/override/bnxt_en.ko version: 1.10.3-231.0.162.0 description: Broadcom NetXtreme-C/E/S network driver license: GPL srcversion: 533BB7E5866E52F63B9ACCB alias: pci:v000014E4d0000D800sv*sd*bc*sc*i* ... alias: pci:v000014E4d00001604sv*sd*bc*sc*i* depends: devlink,ipv6 retpoline: Y name: bnxt_en vermagic: 4.19.0+1 SMP mod_unload modversions # dmesg|grep bnxt_en [ 15.047312] Broadcom NetXtreme-C/E/S driver bnxt_en v1.10.3-231.0.162.0 [ 15.048046] bnxt_en 0001:5c:00.0 (unnamed net_device) (uninitialized): Device requests max timeout of 60 seconds, may trigger hung task watchdog [ 15.215453] bnxt_en 0001:5c:00.0 eth0: Broadcom BCM57508 NetXtreme-E 10Gb/25Gb/50Gb/100Gb/200Gb Ethernet found at mem 2affff010000, node addr 40:5b:7f:6e:22:00 [ 15.215469] bnxt_en 0001:5c:00.0: 252.048 Gb/s available PCIe bandwidth (16 GT/s x16 link) [ 15.216606] bnxt_en 0001:5c:00.1 (unnamed net_device) (uninitialized): Device requests max timeout of 60 seconds, may trigger hung task watchdog [ 15.265361] bnxt_en 0001:5c:00.1 eth1: Broadcom BCM57508 NetXtreme-E 10Gb/25Gb/50Gb/100Gb/200Gb Ethernet found at mem 2affff000000, node addr 40:5b:7f:6e:22:01 [ 15.265372] bnxt_en 0001:5c:00.1: 252.048 Gb/s available PCIe bandwidth (16 GT/s x16 link) [ 15.350702] bnxt_en 0001:5c:00.1 side-5183-eth1: renamed from eth1 [ 15.385121] bnxt_en 0001:5c:00.0 side-3345-eth0: renamed from eth0 [ 17.400142] bnxt_en 0001:5c:00.0 eth0: renamed from side-3345-eth0 [ 17.493640] bnxt_en 0001:5c:00.1 eth1: renamed from side-5183-eth1 [ 20.614447] bnxt_en 0001:5c:00.1 eth1: NIC Link is Up, 100000 Mbps (NRZ) full duplex, Flow control: none [ 20.614454] bnxt_en 0001:5c:00.1 eth1: FEC autoneg off encoding: None [ 21.113687] bnxt_en 0001:5c:00.0 eth0: NIC Link is Up, 100000 Mbps (NRZ) full duplex, Flow control: ON - receive & transmit [ 21.113694] bnxt_en 0001:5c:00.0 eth0: FEC autoneg off encoding: None