@danp said in XCP-ng 7.5.0 final is here: @dblogic said in XCP-ng 7.5.0 final is here: Just tried updating our pool and after updating the master had failed migration of VM (Ubuntu) and then was unable to get VM to start (Missing VDI error). Only solution was to roll master back to 7.4 and everything working again. I ran into a similar situation when I upgraded to 7.5 this week. Did you check to see if there was a non-existent ISO mounted in the CD rom for the VM in question? Thank you. That was my problem. I gave cd empty. Everything works.

@julien-f I just wanted to update and let you know that whatever changes you made fixed the issue for me permanently! I have been able to routinely update since that time and have had no further issues. Thanks for all of your hard work, Julien-f!

Actually, looks like I had already written something about it in the Updates Howto: https://github.com/xcp-ng/xcp/wiki/Updates-Howto#a-special-word-about-xcp-ng-75-76-and-live-migrations

@tcorp8310 yes yum update should do the trick

Good to know it works now Thanks for the feedback!

@rauly94 Hello everyone. Anyone can help me on this issue. Now it started happening on 2 vm's instead of 1 vm. It is happening on the backup replication. Error: VDI_IO_ERROR(Device I/O errors)This is a XenServer/XCP-ng error Start: Jul 5, 2023, 09:03:18 AM End: Jul 5, 2023, 09:44:46 AM Duration: 41 minutes Error: VDI_IO_ERROR(Device I/O errors)This is a XenServer/XCP-ng error Start: Jul 5, 2023, 09:03:09 AM End: Jul 5, 2023, 09:45:12 AM Duration: 42 minutes Error: VDI_IO_ERROR(Device I/O errors)This is a XenServer/XCP-ng error Type: delta

anyone can request a change in https://github.com/xcp-ng/xenadmin/issues

@cg Those HDD's will take their fair time to rebuild. Always stressful looking how far along it is while crossing your fingers that another drive wont pop during the process.

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

@stormi dd stands for disk dump and does exactly that: Copy a stream of data. Fio however can be configured for precise workloads and read/write mixes, parallel workloads etc. So the first thing will only give you streamline benchmarks, what almost nobody cares about. The second can simulate realworld (VM/database...) workloads, where (controller) Caches and non magnetic storage (Flash, Optane, MRAM...) makes the real difference. Also use big amount of data, since caches can impact small ones extremely. Don't get me wrong: We need them and they can make huge differences, but as long as your benchmarks fully fit into them, it gives your nonsense/fake results. Also (consumer) SSDs start throttling after some 10 to a very few 100 GB of data written. Their caches fill up and they 'overheat'. You can spend days on benchmarks and how to do what.

@MathieuRA said: Hi, regarding your backups which do not appear on the XO5 restore page, I suggest you to open a new topic Forgot to include the link to the new topic https://xcp-ng.org/forum/topic/12040/restore-only-showing-1-vm

@TrapoSAMA All of mine are 2022, but saw this in previous driver versions with 2025. Low priority on this so I haven't fixed it yet.

Great news and also great feedback! I think we'll add this in our guide

Thanks for your feedback lads!

@florent Great work, thanks for the fixes

@high-voltages Just wanted to thank you again, its working now with the commands i did in the screenshot.

@flakpyro said in Switching to XCP-NG, want to hear your problems: @CodeMercenary I am using V4 on the XO-Server to our backup remotes and it seems to work just fine. However using V4 as a storage SR was nothing but problems, as @nikade mentioned we had tons of NFS Server not responding issues which would lock up hosts and VMs causing downtime. Since moving to v3 that hasn't happened. Checking a host's NFS retransmissions stats after 9 days of uptime i see we have had some retransmissions but they have not caused any downtime or even any timeout messages to appear in dmesg on the host. [xcpng-prd-02 ~]# nfsstat -rc Client rpc stats: calls retrans authrefrsh 268513028 169 268537542 From what a gather from this blog post from redhat (https://www.redhat.com/sysadmin/using-nfsstat-nfsiostat) it seems like that amount of retransmissions is VERY low and not an issue. Thats fine, we've got a lot more and I haven't seen any "nfs server not responding" in dmesg yet. Using NFS v3 for both SR and backups now for a couple of years and it's been great, I think I had issues once or twice in like 5-6 years on the backup SR where the vhd file got locked by dom0, Vates helped out there as always and it was resolved quickly.

@florent Nothing large. Either 10 or 20GB. I'm thinking it's due to the same issue as here.