Best posts made by XCP-ng-JustGreat

@stormi Installed all of the test updates on my three-host home-lab this weekend. Similar configuration to @gskger 3 x Dell OptiPlex 7040 SFF hosts and home-built FreeNAS server with separate physical 1Gb networks for management, storage and migration. I call it my "Tiny Cluster" due to its diminutive footprint. I use it for configuration prototyping. Intel VPRO AMT on Xen hosts and storage server enables headless console operation using MeshCommander (think poor man's iDRAC). All updates were installed without issue. Backups and restores seem to work just fine. Of special interest to me was the UEFI Secure Boot capabilities. Installed the x64 dbx.auth from uefi.org (I presume since XCP-ng is 64-bit that that was the correct choice. Probably should be made explicit in the instructions.) Seems to work perfectly. I tested with Windows 10-20H2 and Windows 10-21H1. Also tested with RHEL 8.4 which has built-in support for secure boot (Microsoft-signed bootloader shim) and that too "just works." The varstore-ls <VM-uuid> command shows PK, KEK, dbx and db in the store as expected. Stops unsigned bootloader as expected on unsupported OSes. Looks great! Thank you for all of the work you've put into it. I suspect designing and building emulated system firmware is not for the faint of heart . . . Very impressive!

Latest version 8.3 candidate updates installed and are working fine on three-host home lab pool. Received a couple of repo errors for a certain mirror, but yum tried another mirror and it completed successfully. After updates were applied, performed live migrations between hosts with no problems and updated a Windows 11 Version 24H2 VM to the November 2024 cumulative update without problems. (VM is currently running Citrix Tools 9.3.2 without issues.)

Applying the latest XCP-ng 8.3 RC2 "xen-*" and intel-microcode updates from the candidate repository worked great here as well. Everything appears to be running well.

Latest updates over ISO-installed 8.3 RC2 worked fine for me. I did experience one host in my three-host pool to which no VMs could be migrated. After looking at the networking from bash in DOM0, it showed that both 10G ports for the storage and migration networks were DOWN. These ports are on a genuine IBM-branded Intel X540-T2 card I bought used on eBay so it might have gone bad. Since the card has worked well for some time, I figured it couldn't hurt to re-seat it in the PCIe slot. Sure enough, that fixed it. Moral of the story: check the mundane stuff first; it's not always the fault of new updates.

Upgraded 3-node pool (home lab: Dell OptiPlex 7040 SFF x 3) from 8.3 RC1 to 8.3 RC2 using bootable ISO. It worked perfectly for me. As others have noted, it does ask you to select the management interface when upgrading the slave nodes. Once you do that, it automatically populates all of the previously configured network parameters for that host so you are really only confirming the existing values. The OptiPlex 7040's (i7-6700) all have Intel VPro AMT so they are running headless. The MeshCommander program is used to access the VPro console on each host. A DisplayPort display emulator dongle is needed to keep the integrated-GPU active in order to be able to see the console and firmware setup screens with this configuration. It's effectively a poor man's iDRAC. So far, everything is working well on 8.3 RC2.

@stormi All new patches applied fine. No apparent problems identified so far.

@beshleman I tried the latest testing update @stormi published with the updated SB support and it does indeed work properly including allowing installation of Windows Update KB4535680 on Server 2019 as previously cited. Also--a big thank you for adding the default parameter values for the improved secureboot-certs install command. Less is more. Very nice!

@beshleman So, after yum --enablerepo=base install python-requests on each of my hosts, secureboot-certs install default default default latest works perfectly. (Cool that it installs certs to each host in the pool with one invocation from any pool host.) Interesting that it doesn't install the three files to /var/lib/uefistored until you secure boot a vm on each host. I went looking for them and was initially confused because they were only written to the pool db. Serves me right for looking under the hood! Looks like XCP-ng secure boot is ready for prime time. Great job!

@stormi So far, I have tested a fresh install using software RAID mirror creation. Works fine. Also, noticed the new EFI boot kludge to correct missing bootloader on Dell and other faulty UEFI firmware. (I used to always add the /boot/efi/EFI/boot/bootx64.efi file to correct this since it also occurs on my ASUS-motherboard machine.) That works well. The newly refreshed secureboot-certs install default default default latest command is not working. The requests python module is not being found. BTW, I think the default option where the command is secureboot-certs install should be equivalent to adding default default default latest parameters @beshleman . I'll continue to test and report back later.

@noship Hello. The secure boot feature is currently available as pre-release code. My personal experience is that it works well for my use case. Some others are reporting boot issues after installing the updates so it continues to evolve and is not yet released for production. Search the forum for UEFI and you will find the relevant threads for obtaining and installing secure boot support. Here's one: https://xcp-ng.org/docs/guides.html#guest-uefi-secure-boot

@stormi @olivierlambert It looks like we now have the attention of Andrew Cooper at Citrix. For anyone interested in following or participating in the Xen developer list nested virtualization thread we originated, it begins here: https://lists.xenproject.org/archives/html/xen-devel/2021-07/msg01269.html (Just click Thread Next to go through it sequentially.) For the purposes of that list, I have become Xentrigued. Cooper readily admits that nested virtualization in Xen is "a disaster" and has suffered from neglect. With the upcoming launch of Windows 11 and Server 2022, nested virtualization of Hyper-V and, likely, vTPM 2.0 support will become "musts" for hypervisor certification by Microsoft so there are some strong tail-winds that may aid in pushing this forward beyond the XCP-ng community. I will try to be of some use toward that end.

@stormi Sounds good. We'll wait for the wizards at Vates to do their thing. With great admiration and appreciation for all that you do. XCP-ng just keeps getting better and better! We thank you!!

@julien-f @olivierlambert I've said it before and I'll say it again: "Wow, that was fast!" You guys do more to foster international cooperation than most of our planet's governments. Keep up the great work. Thank you Vates for creating, maintaining and improving this fantastic software!

@Andrew Sorry, I should have added that it remains broken in the latest master commit 8b7e1.

Applied recent 87 updates to 3-node home-lab pool running XCP-ng 8.3 using XO from source on the latest commit. The update worked perfectly and a mix of existing Linux and Windows VMs are running normally after the update.

Stats are back in XO after latest XCP-ng 8.3 updates and compiling XO from latest source. That was fast!

@john-c @stormi @olivierlambert All, given the complexities involved in providing an automated solution for this issue, it may make the most sense at this time to mitigate any negative outcomes using an installation/update warning. For instance, throw a message dialog issued by both the ISO installer and the pool update feature in XO such as: WARNING: One or more of the pending updates may alter your VM's firmware. If you are using Microsoft BitLocker to encrypt virtual drives, you should exit now and suspend BitLocker prior to performing this update. (Provide customer with Exit or Continue buttons with Exit selected by default.)

@olivierlambert @stormi Here's a good link for persistent disablement of driver signature checking on Windows using bcdedit https://blog.pcrisk.com/windows/12194-how-to-disable-driver-signature-enforcement that may help those above wanting to use the XCP-ng drivers. If for some reason that doesn't work, they can, of course, use the signed Citrix drivers as a stopgap measure.

Serious movement appears to be happening with respect to NV. See videos below cross-posted from this forum thread:

https://xcp-ng.org/forum/topic/8932/hardware-assisted-virtualization-is-not-enabled-on-this-host-even-though-platform-exp-nested-hvm-true-is-set/52

Nested Virtualization (X86) Part I - George Dunlap, Xen Server:
https://www.youtube.com/watch?v=8jKGYY1Bi_o

Nested Virtualization (X86) Part II - George Dunlap, Xen Server:
https://www.youtube.com/watch?v=3MxWvVTmY1s

@alexanderk @olivierlambert Sorry to have not responded sooner to your question. It has been a very long, slow slog so far and I haven't been able to devote as much time as I'd like to working on this. Here's what I've done so far: Based on Andrew Cooper's recommendation, I installed a fully patched Windows Server 2008 R2 VM to Xen. (Hyper-V was initially released with Server 2008 so this is almost as far back as you can go.) Using the current unmodified Xen source code, the VM will permit Hyper-V to be enabled in the Windows Server 2008 R2 guest, but--as with newer versions of Windows--once you perform the finishing reboot, Hyper-V is not actually active. Adding the two recommended source-code patches, recompiling and performing the same test causes the VM to hang following the enablement of Hyper-V. I know that I need to set up a serial console for the VM in order to view any logging that might provide a clue as to what's failing during the boot, but I haven't worked that out just yet.

I've also spent some considerable time reading through the Xen Dev email posts on the history of the development of nested virtualization in Xen. One very significant learning from that reading is that nested virtualization on Xen was initially developed by an AMD developer. Development of the NV feature-set for Intel came later after the AMD-focused design die had been cast. As far as I can tell given that I'm running Server 2008 R2, this never worked on Intel. (Maybe it did on an older Intel processor, but I am currently working with SkyLake i7-6700s so have no way to test older hardware.) Unfortunately, I also don't have appropriate AMD hardware on which to perform the same test to see whether or not it might work on AMD.

On the Microsoft Hyper-V side, it seems as though the opposite evolution happened. Nested virtualization was developed on Intel first, then (very recently) AMD. This makes me suspect that it doesn't work on AMD either. In other words, I don't know that nested virtualization of Windows on Xen ever worked such that Hyper-V was actually active in the guest. I would be delighted to have somebody prove me wrong.