We experience the exact same issue with CloudLinux OS 8, seemingly random after live migration. This has been ongoing for years. Seems to happen far less now with shared storage. My theory somehow the kernel and/or PVE module doesn't handle the freeze during live migration, longer freeze, more risk of this happening. VMs start to crash random amount of time after live migration, never immideate. Could be hours, or days even, making it hard to diagnose. No crash dump, nothing, just 100% CPU on all cores and frozen console. One consistent thing we see, that happens almost every time, is that top and other tools stop working, they are frozen in a state were no CPU load etc is reported, but there is load on the server. We've been going back and forth with CloudLinux support and they did some changed to tuned profile regarding disk buffers/cache that made things at bit more stable but not gone 100%. We don't see the same error in AlmaLinux 9 and CloudLinux OS 9. More busy VM = more chance of happening. Uptime may be a factor, too.

@melthoab See the documentation -- https://docs.xcp-ng.org/vms/#️-guest-tools

@KPS it should be "yes" of course. Typo!

@KPS I don't know why my brain has decided to index all the xcp-ng forum, so when I read your post, I immediately remember the post with the clonezilla issue

@hvm said in Guest receiving passthrough SATA controllers does not see attached drives: @Teddy-Astie Hello @Teddy-Astie Have you had the opportunity to review the log file output? The past few weeks I have spent a lot of time trying to find a solution. But unfortunately after all the things I have tried, none of them have solved or did changed something to the problem. We are investigating the possibilities to run our branch locations environments with XCP-NG. This requires a working PoC where passthrough of this SATA controller is necessary.

@Andrew It's interesting because I actually had one of the previous versions of the OVA running in XCP and now that VM halts in the same place so it appears something changed on the XCP-NG side.

@Danp It is quite a varied basket. All VM's are linux. Some VM's migration directly from vmware, some were imported vmdk, some were OVA's. The several Ubuntu VMs used the Ubuntu template, some of the other's were AlmaLinux 8. Most were modified in the Advanced settings after the VM was up and running. All have CPU weight at 256. Hyperthreading and Turbo are all enabled.

@FTSSupport Got it! I'm not sure there is a way around hyper-v complaining on that front unfortunately.

@jpasher-work The jammy repository is providing xe-guest-utilities 7.20.2 The "guest-tools.iso", that is provided by XCP-ng offers 7.30.0-12 mkdir /mnt/cdrom mount /dev/cdrom /mnt/cdrom /mnt/cdrom/Linux/install.sh

anyone who solved this problems, could you share how to solve the bug? xen 8 with xcp ng centre 20 could not run autostart vm

great news then

@nick-lloyd I think the answer would depend on the state of your XAPI database given the fact that each host thinks that it in the pool master. To convert one or more of the hosts to a slave, you would need to -- edit the file so that it contains slave:<IP address of master> instead of master run mv /var/xapi/state.db /var/xapi/state.db-old to get rid of the old xapi database reboot the host Once rebooted, the xapi database will be regenerated by syncing with the pool master.

Hi, I think that's a XAPI behavior, I'm not sure it's propagated when the VM is migrated. You might ask upstream XAPI project about this

There's no stupid questions, only bad UX/UI

No, it really depends on many factors. There's no universal tuning.

@JacobyBarr said in Windows 2022 server not rebooting: It was quite frustrating, to say the least! I found that sometimes it's down to updates or even some funky settings in the BIOS. Have you checked those yet? I think, its not an option, to stay on a patchlevel prior to 02/2023... Did you try to disable secure-boot?

@Kajetan321 You should consider the effects of NUMA/vNUMA in terms of performance. Crossing over to other physical CPUs or memory banks will create slowdowns. If possible, unless you absolutely need all those VCPUs on any or both VMs, you may be best off splitting the 36 VCPUs and assigning 18 on each VM, checking to see if all the memory stays with the bank(s) of those specific VCPUs. See my articles on the CUCG site about NUMA and in particular, graphics performance (and of course, calculations will also be affected). Best would be to run benchmarks with both configurations. Shrinking the number of VCPUs on a running VM can lead to issues (as indicated in the video posted just before my response). See the Tale of Two Servers articles here for details: https://community.citrix.com/profile/46909-tobias-kreidl/#_=_

If it's only the XAPI that was damaged, you can restore metadata from your XO/Pool metadata backup. Alternatively, if you forgot to make metadata backup, you can introduce SR to find back all your previous disks (but you will lose the medata data with it).