@SethNY said in Windows 11 WSL2 is not supported with your current machine configuration:

XCP-ng 8.3, XO from sources.
Created Win11 from ISO using the built-in Windows 11 template
Configured and turned into template for cloning.

Trouble installing WSL on the cloned Win11:
WSL2 is not supported with your current machine configuration

This worked a couple years ago Win10 on XCP-ng 8.2, Ubuntu 22.04.

From administrative powershell

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
(Accept the reboot, back to administrative powersehll)
wsl --install
(fails)
wsl --list --online
wsl --install -d Ubuntu-24.04
(fails again)

I tried enabling Nested Virtualization for the VM without success
Booted to (F2) BIOS and confirmed not virtualization options there to enable

Has anyone got Win11/WSL/8.3 working? I'm hoping it's not due to not installing a Windows license key.

You were probably using WSL 1 before, and now using WSL 2 (which requires Hyper-V thus nested virtualization). And I'm not aware of WSL 2 working on XCP-ng 8.2, I assume you were actually using WSL 1 previously.

You can use WSL 1 by using

wsl.exe --set-default-version 1

and

wsl.exe --set-version <Distro> 1

@McHenry said in pfSense Guest Tools:

I have been using pfSense with xcp-ng for a while now without installing the guest tools.

Due to some networking complications I have decided to install the guest tools to eliminate this as the cause.

Q1) Are the guest tools required on pfSense and what do they do?

Actually no, their main functionnality is to provide some data (memory usage, IPs) to XCP-ng to report them upward, AFAICT, it doesn't impact behavior in a significant way. It's actually not "PV drivers".

Q2) Are these tools being maintained?

This version of the guest agent is very limited and ancient (I don't exactly what it does, but not much IIRC).

We're working on a new guest agent in Rust, which actually works pretty well on Linux, Windows (actually used in latest Windows drivers) and FreeBSD (NetBSD is also possible, but current code lacks some platform-specific bits). But we still need to sort-out some issues (some technical and some others non-technical) before making it broadly available / making it packaged.

@Maelstrom96 said in Epyc VM to VM networking slow:

What is the exact kernel patch that is required for the xen-platform-pci-bar-uc=false fix to work on a Linux guest? We're looking at potentially compiling our own kernel with the xen-netfront.c patch, and we would like to see about adding the other part of the Kernel code needed for the Grant table fix.

Patch is in Linux since 5.19-rc. You also find it in some stable branches like 5.15.

Otherwise, you can check this patch https://lore.kernel.org/xen-devel/ea4945df138527ed63e711cb77e3b333f7b3a4c9.1751633056.git.teddy.astie@vates.tech/

@joeymorin said in Building from source fails with commit cb96de6:

Greetings all,

Subject pretty much says it. Build output goes sideways starting with:

@xen-orchestra/qcow2:build: src/disk/QcowDisk.mts(94,52): error TS2365: Operator '&' cannot be applied to types 'bigint' and 'number'.

Github CI is failing on this commit, try reverting to a commit that pass CI.

@rk9268vc said in Having issues installing StartOS as a VM. Cant detect a disk for it to install to.:

@TeddyAstie so can i just not run this OS on xcp-ng? is there no workaround? Would this run on proxmox?

you can try adding to Linux command-line (in grub) xen_emul_unplug=never to disable PV drivers, thus making udev see ATA/NVMe drivers, maybe that's enough as long it's only the installer

@rk9268vc said in Having issues installing StartOS as a VM. Cant detect a disk for it to install to.:

@TeddyAstie so is this fixed in a newer version of xcp-ng? and if so, can i update live?

it's not fixable from XCP-ng side, it is a bug in Debian/others...

This happens because StartOS uses /dev/disk/by-path to get disk list and due to missing rules in 60-persistent-storage.rules (thus systemd/udev), Xen PV disks don't get their disks populated in /dev/disk/by-id.

In other words, it is a systemd bug which wants to be fixed, but getting that backported to older distros is gonna get tricky.

@Maelstrom96 said in Kioxia CM7 PCIe pass-through crash:

@TeddyAstie It's a newly deployed Rocky Linux 9.6 with all the latest updates applied to it.

Nested virtualization is disabled.

Can you do

xl debug-key G
xl debug-key +

and try restarting the guest to try having more informations.

Also, note that your installation is not up to date (even though I don't think it is going to change anything).

What guest you are trying to boot ?
Is nested virtualization enabled for this guest, if it is enabled, does that work if you disable it ?

@mickwilli said in Cannot Install Windows 10 in New VM:

@dinhngtu Thanks. I'll try and give that a go in the next few days and will report back.

Note that I have Windows 10 1803 installed without any issues. Trying to update to 22H2 fails with the same blue screen error as you'd expect. Sadly, no crash dump as it seems to fail very early in the boot process.

Do you get any additional BSOD details in xl dmesg ?

I've seen cases where the a hard reset is forced in case some devices can't DMA. Maybe it's related.
If that's the case, something should show up in the IPMI, and the crash is usually instantaneous; otherwise, there is some delay (~5 seconds) between Xen/Dom0 crash and actual reboot.

@chicagomed said in Passthrough Contention Problems with Console and Linux VM:

@TeddyAstie great will take a look this weekend. Is there anything in particular you want us to test / check out?

What works/doesn't work and overall performance.

@DustinB said in Passthrough Contention Problems with Console and Linux VM:

@olivierlambert yes please

It's something we're still evaluating, and there are known bugs (including some for unknown reasons).
There are still rough edges, not everything works perfectly; but it's somewhat there.

What works (tested) :

• UEFI guests (OVMF knows how to drive virtio-gpu devices)
• Linux operating systems with virtio-gpu drivers
• High resolutions

What doesn't work :

• VGA compatibility mode doesn't work properly
  • BIOS guests have no display at least at the beginning
  • operating systems without virtio-gpu drivers may or may not work properly (e.g Windows without appropriate drivers), but that still wants to be tested
• cursor integration is a bit limited in Xen Orchestra (may not match guest cursor icon); but at least you don't see duplicate cursors

To test it (not production ready)

# Download repo file for XCP-ng 8.3
wget https://koji.xcp-ng.org/repos/user/8/8.3/xcpng-users.repo -O /etc/yum.repos.d/xcpng-users.repo

yum update --enablerepo=xcp-ng-tae1

you should see virtiovga packages for QEMU and Xapi.

Then, you set virtio-vga for your VM.

xe vm-param-set uuid=GUEST_UUID platform:vga=virtio

(or vm-param-add depending on whether or not the parameter has been set previously)

Regarding Windows support; KVM VirtIO drivers provides a "virito-gpu DoD" which should work (tested with upstream Xen, but not yet with XCP-ng).

Hello,

Make sure Intel VMD is disabled (this is the hardware RAID feature of Intel, and it doesn't currently work on XCP-ng; you probably don't need it unless you are looking to make a RAID). We found some modern platforms enabling by default (which also causes issues with Windows).

@emuchogu-0 said in AI on XCP‑ng 8.3: Not Ready for Prime Time? FlashAttention/ROCm Passthrough Stalls vs Proxmox & Bare‑Metal:

xl dmesg (dom0) and dom0 dmesg
Guest dmesg filtered for amdgpu, rocm, hsa, xnack, pasid, iommu, fault messages
Guest lspci -vv for the GPU (MSI/MSI-X state, BARs)
rocminfo from the guest
Minimal reproducer scripts for llama.cpp and ollama (FlashAttention on/off)

You need to provide this information; we can't blind guess where something is failing.

@john.c said in XCP-ng 8.3 updates announcements and testing:

I don’t have AMD based hosts for XCP-ng. However may I suggest an additional validation test of this change, against Debian 13 when stable is released during or following tomorrow. I recon it should work - newer Linux Kernel version 6.12 series, though can’t be sure! Best check to avoid nasty surprises.

The performance fix support is related to the kernel version. All kernel >= 5.19 work with it (or that have https://lore.kernel.org/all/20220530082634.6339-1-jgross@suse.com/), this includes Debian 13.

16 EIB is pretty close (1 byte close) to 18446744073709551615 bytes, which is the maximum representable 64-bits number.

Unikraft would a a good fit for ram-constained devices.
Being able to have useful VMs with 32-64 MB each.

@deefdragon said in VM UUID via dmidecode does not match VM ID in xen-orchestra:

Out of curiosity, I dumped the DMI into a bin and opened it up in a hex editor.

I am seeing ASCII of the ID, but also a variant encoded in binary. In both cases, its formatted as 0b08f477-491a-a982-23c4-d224723624ea.

I believe the ASCII version is the one that gets populated into the serial number as it comes after ASCII encoded versions of the 3 lines above it in the decode.

In SMBIOS 2.8, the UUID is supposed to be encoded in little endian (i.e Microsoft GUID). Yet it is put as big endian instead. So when Linux generates the UUID string from the SMBIOS table, it is considered as little endian which causes this mismatch.

SMBIOS 2.4 is supposed to be used (which appears to be using big endian UUIDs), but for some reason, something in XCP-ng UEFI supports forces it to be SMBIOS 2.8.

So the binary UUID is the same, just that it is interpreted with a different endianness due to accidental format change.

@lovvel from a software standpoint, this is a 16 cores CPUs and AFAICT, Xen doesn't account for these slight differences between cores.

As to be fair, it's not really easy to know in practice if a 3D-VCache core will be faster than a non-3D-VCache one for a specific case.