I've tried an experiment and modified slightly qemu-wrapper script to not add cirrus-vga device to the VM. THe VM starts, but I still have no signal on my HDMI output. Seems like more work needs to be done in order to use my iGPU for display on HDMI output... Browsing through similar topics on the forum it seems like it's not a supported use case? Are there any plans to support this use case?

@Tackyone You solution fixed it for me. Lost a few days of logs as well and i am on the latest commit of the XO community edition. Theres some bug with syslog clear but your fix works great.

@enes-selcuk Did you find a setting that works best w/ Dell servers? I have a Dell R640's which I'll be using for LAMP/LEMP vm servers and was wondering what are the best settings to use in Dell Bios and if there are any changes I need to make on the xcp-ng host? Dual Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz Level 2 Cache 16x1 MB Level 3 Cache 22 MB Number of Cores 16 Dell Bios Setting: System Profile: Performance Per Watt (OS) CPU Power Management: OS DBPM Memory Frequency: Maximum Performance Turbo Boost: Enabled C1E: Enabled C States: Enabled Write Data CRC: Disabled Memory Patrol Scrub: Standard Memory Refresh Rate: 1x Uncore Frequency : Dynamic Energy Efficient Policy: Balanced Performance Number of Turbo Boost Enabled Cores for Processor 1: All Number of Turbo Boost Enabled Cores for Processor 2: All Monitor/Mwait: Enabled Workload Profile: Not Available CPU Interconnect Bus Link Power Management: Enabled PCI ASPM L1 Link Power Management: Enabled Thank you! SW

@stormi oh I see, I'll check the windows 10 vm's then, thank you

I'm taking another look and it looks like the tools may be under another name... xen-tools I may be going blind at this point if I've missed it this many times.

Ya, for the working machine I just had to run opt/xensource/libexec/xen-cmdline --set-dom0 "xen-pciback.hide=(0000:00:02.0)" and on next reboot I could add the GPU as pass through in XOA. for the other machine this didn’t work but using xcp-center did make it show up as a pass through option

@stormi said in Nested Virtualization of Windows Hyper-V on XCP-ng: Actually, Xen never officially supported Nested Virtualization. It was experimental, and broke when other needed changes were made to Xen. Now there's work to be done to make it fully supported, and this won't happen before the final release of XCP-ng 8.3. This will be documented in the release notes. This is also an issue for us internally as we create a lot of virtual pools for our tests. I read through a lot of the earlier posts and finally started scrolling to find this, which is the answer I was looking for. Why do I care? There is a Microsoft evaluation learning lab for things like Intune that runs in Hyper-V, basically a bunch of VHD (x) that get spawned as needed. Applications I need to teach myself. Running XCP-NG 8.3 current updates for this lab. If it doesn't happen, then I'll just need to throw an eval version of Windows Server on something else like an HP T740 to run these labs, not the biggest issue for me. Link for the labs if anyone is curious (free with an email registration like all the evals): https://www.microsoft.com/en-us/evalcenter/evaluate-mem-evaluation-lab-kit I'd think direct Docker support would be a higher priority than nested virtualization with a focus on Hyper-V. But that's just me.

Hello! My apologies -- I hadn't gotten around to trying this solution out until now. I just did and it appears to have fixed the issue! VMs are booting correctly and I can interact with them normally through the console. Can also confirm it works on both the 1.29 Dell FW from my original post, as well as the latest 1.32 FW available as of this post. Much thanks @andyhhp and @stormi for both your time and effort in packaging this -- I greatly appreciate it!

A VM's UEFI variables are not supposed to be erased after a migration . What kind of migration was it? Can you describe the exact operations, and whether the storage is local or shared?

I initially did try grub directly but never got the results I needed. (Could be user error) It's nice to change the resolution down because a lot of our installs have service monitors...ie monitors in the corner that were dusted off and used. I would like to see that "boot to firmware" option either in the boot loader hierarchy or as a select-able toggle. It would help on those few times I need to adjust things but my trigger finger is too atrophied to nail that esc.

@olivierlambert Meant to reply to a message in a different forum - Thanks.

@topsecret Another option is to run a hardware network time server which uses an atomic clock. Then point the NTP client for the systems of your client at that hardware time server. You can choose one of the following hardware time servers:- https://www.microchip.com/en-us/products/clock-and-timing/systems/enterprise-network-time-servers/syncserver-s600 https://timetoolsltd.com/products/network-time-server-appliances/ https://www.oscilloquartz.com/en/products-and-services/ntp-servers https://chronos.uk/products/sync-timing/ https://safran-navigation-timing.com/solution/timing-and-synchronization/ For clients which can't have internet at all even for NTP time synchronisation then running a hardware time server is a must for the network. That way all of the clocks will then be in sync with each other.

There's 2 things: VM placement during VM start, which is decided by XAPI (the host toolstack). Due to the amount of resources, there's no reason to spread the boot on different hosts. This might change depending on various factors. VM balancing while it's running, that's for XO load balancer plugin. But there's also some rules to have enough resources usages to trigger In other words: everything is normal in your case.

@olivierlambert You are totally right. I 'thought' I had added a firewall rule to allow incoming NTP requests, but I added it again and reloaded and now all three hosts are syncing. Thanks!

@melthoab Try changing your static max to 8GB.

See my reply in your other thread. Your VM is either our of disk space or your Redis database is damaged.

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.