@AlexTheBest great work and effort alex , and welcome to modern storage .

Hey, @stevewest15 - I'm going to echo Olivier here. I stumbled across this posting (sorry for being a couple of months out) because I was looking for the right procedure to change my MTU to 9k - based on a recommendation from iX Systems (we have a TrueNAS Core X10 from iX). My two XCP-NG boxes have 10G NICs and the X10 has a dual 10G NIC LACP bond. I was seeing, frankly, disappointing numbers when I watched port statistics on the 10G switch; I never really got above ~2G even on the LACP bond while doing a backup from the pool to the pool's backup SR. After reading Olivier's response to you, I thought I'd iperf it without changing the MTU. Olivier and his team are a bunch of REALLY smart people, and I'm inclined to believe what they tell you... But I'm a strong believer in "trust but verify". Ce n'est pas, @olivierlambert? Anyway, this is what I got just with straight 1500 MTU using iperf3 between one of my XCP-NG hosts and the X10. As you can see, I didn't do any modifications such as paralleling or MSS settings. Just a raw test: [image: 1691080423925-c67a394b-c7b8-4345-b1de-93df8f010aa6-image.png] The 10.11.11.0/24 network is our non-routed SAN/NAS network. While pushing to 9k MTU (don't forget to look at MSS as well) might help these ~80% utilization numbers, the real issue in my mind is the gap between the ~2G I was seeing and the raw numbers above. This tells me that there's something else afoot here. A few thoughts: TrueNAS encryption. If the target is encrypting/decrypting data on write/read, you're going to see significantly lower numbers My initially disappointed observations were during backups. Again, there's a lot going on under the hood that could be affecting performance before it even gets to the wire (or glass, as in my case). Perhaps I need to look at what I can do to tune NFS itself Changing the MTU (and probably MSS) is absolutely a valid thing to do, but every device in the path needs to be adjusted as well. And 5 years from now, when you go to replace the switch, or a NIC, or the storage array... Are you going to remember? I've been in that situation... and I didn't. Hopefully you're smarter than me! iPerf is showing that there's probably 20% in overhead on my SAN, which is something worth looking at, but at this point it's not an outrageous number - particularly since I'm not even coming close to touching that number during normal ops. It's worth a Wireshark though.

@olivierlambert so I went to restore this VM from backup, and noticed that the monthly backup is currently running on this VM as we speak. Will restoring from this newest backup fix my issue? Or does it restore the issue back into production?

works. thanks!

@Andrew This was the answer, thank you! I had it set with 8MiB of video memory which was fine with an older install but 22.04 needs more it looks like. Bumped that up to 16 MiB and it's super smooth now. Thanks for your help! @olivierlambert increasing the video memory was the solution. But to answer your question this was in BIOS mode rather than UEFI.

@MathieuRA Indeed, that's the right way to do it, I think

Hopefully, we'll make things more obvious in terms of "danger zone" in XO 6 UI

I have opened a ticket to support because file level restore doesn't work anymore after latest update. Best regards Walter

Look under the configuration for the backup-reports plugin, which can be found under Settings > Plugins.

@julien-f Hmm, that's a bit disappointing that there isn't much you guys can do to help. No worries, I'll keep testing. My AD environment works fine, since the accounts in question are not locked and are being used daily. The only place they're failing is in XOCE or XOA. It's gotta be something with how the library is handling characters in either the username or the password. I'll keep testing until I can find a repeatable pattern. Thanks to both you and @olivierlambert for the help thus far.

@kamal8641 AWS S3 remote on xen orchestra works fine in my tests.

thanks for all advices just moved all services to new vm, that makes topic is closed. for last try i updated xen 6.5 to 7.4 but problem remains

@olivierlambert Hahaha you got it! Thank you

Hi there Gsrfan Apologies for the delayed response, I had to shelf this passion project to focus on other work So far managed to get the host, static IP, packages, users & their keys/password etc sorted with the init I was working last on lvm partitions, to grow them and that ended up a bit of a mess I might return to this at a later stage but I found your help and advice invaluable to getting the config to where it is now Thank you so much

@olivierlambert said in file restore on large backups ends in print_req_error: I/O error's: Yes, that sounds the next step to do Something is wrong during the mount phase. Also check you have enough RAM in your XOA. Ok, filesystem checks out - as far as I can see having: Done full restore of VM from the same Delta image. Booted VM, logged in and done 'tar cvf /dev/null *' of the filesystem I'm trying to restore from - which ran to completion without error. I upped the RAM for XOA from default 2GiB to 16GiB and re-tried - and same result. I can try yet more RAM if needs be but would hope 16GiB is more than enough? The console error on XOA is more detailed than my install- so don't know if this helps: blk_update_request: I/O error, dev loop0, sector 8912912 op 0x00:(READ) flags 0x80700 phys_seg 1 prio class 0 Looks to be the same issue, just reported differently. You also (on both systems) get kernel chatter about "tasked blocked" (understandable, as it is).

@olivierlambert said in Can't restore VM's from 'read-only' remote?: A remote (now Backup repository) is meant to write backups into it. If you aren't able to write, then, sure, you can restore but you won't be able to backup anything. Yes, understand that - I'll have to re-test here, but I'm sure when it was 'read-only' - I couldn't restore anything from it, as nothing showed up in XO's "Backup / Restore' list of backups... The remote was mounted on two systems - hence why made R/O for one of them (this was just for testing restores).

@Zevgeny Did you succeed to remove the protection with "xe vm-param-clear"? It didn't worked perfectly for me. Before I use xe vm-param-clear, I have the following: [18:28 xcpng02 ~]# xe vm-param-list uuid=37b7a201-eb45-b7de-5ce4-da25b1c7b547 | grep block blocked-operations (MRW): pause: true; hard_shutdown: true; (unknown operation): true; hard_reboot: true; clean_shutdown: true; suspend: true; clean_reboot: true [18:28 xcpng02 ~]# Now I try to clean: [18:28 xcpng02 ~]# xe vm-param-clear uuid=37b7a201-eb45-b7de-5ce4-da25b1c7b547 param-name=blocked-operations The value given is invalid field: blocked_operation value: (unknown operation) [18:28 xcpng02 ~]# After, "blocked-operations" looks like this: [18:28 xcpng02 ~]# xe vm-param-list uuid=37b7a201-eb45-b7de-5ce4-da25b1c7b547 | grep block blocked-operations (MRW): (unknown operation): true; hard_reboot: true; clean_shutdown: true; suspend: true; clean_reboot: true [18:30 xcpng02 ~]# In the GUI of XOA, the "Protect from accidental shutdown" is removed but not on the command line.