XCP-ng Guest Agent - Reported Windows Version for Servers

plaidypus

Good Afternoon Everyone!

I am really excited for the release of the signed drivers and the guest agent for XCP-ng, so I installed it on one of our servers to test it. Everything went smoothly, but I noticed one thing after the install.

On the test VM, it reports the version of Windows using the underlying version as Windows 10 instead of the server version such as Windows Server 2016 Datacenter. Below is the example. While this isn't a huge deal, since we can manually tag the VM, it is nice that with the XenServer agent we don't have to tag them to make them searchable/filterable on "Windows Server nnnn" in XO. Since we also have Windows 10 and 11 VMs in our environment, the Server 2016 test VM also shows up as Windows 10 in the list.

XCP-ng Agent Windows Server 2016

Xen Server Agent Windows Server 2016

This is what the XenServer agent reports for a Windows 10 install.

As stated above, there is an easy albeit tedious workaround, so this is more feedback than an issue. I also appreciate how the XCP-ng agent does not include all the C:\ drive info that the XenServer agent does. That makes it look cleaner in my opinion.

olivierlambert

Hi!

I think we had a similar feedback recently, let me add @dinhngtu in the loop

dinhngtu

@plaidypus Hello, I'll change it to report the correct OS version (Windows 11 Professional 64-bit, Windows Server 2022 Datacenter 64-bit) in the next version. In fact, the change is already integrated in our code here: https://github.com/xcp-ng/xen-guest-agent/commit/004056c1d6f185077768678944558dd5df5fa45d

0

dinhngtu committed to xcp-ng/xen-guest-agent

Better OS info reporting for Windows

On Windows, the edition matters more than the version numbers. Report
that in data/os_name instead.

For reference, this is what os_info supplies:

display: Windows 10.0.26200 (Windows 11 Professional) [64-bit]
os_type: Windows
version: 10.0.26200
edition: Windows 11 Professional
bitness: 64-bit
archite: x86_64

Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>

olivierlambert

It's funny to see Microsoft having a version 10 for an edition named 11. I suppose it's not a surprise for an organization that huge.

Forza

@olivierlambert said in XCP-ng Guest Agent - Reported Windows Version for Servers:

It's funny to see Microsoft having a version 10 for an edition named 11. I suppose it's not a surprise for an organization that huge.

They did say that Windows 10 would be the last version of Windows...

plaidypus

@dinhngtu Awesome and thank you so much!

When the new version is built, will we need to download it and install from Github or is there another update mechanism?

dinhngtu

Hi @plaidypus, there's no autoupdate for the XCP-ng tools just yet.

I recommend you watch for the releases on our release repository (click Watch -> Custom -> Releases)

Greg_E

@dinhngtu

How soon do we expect this? I'd like to move my production systems off of the Xenserver versions.

Also, if you are willing to disclose this, how much did it cost? Chris Titus did a video or two on the process for his Windows tools, he got them signed so that fewer complaints would happen when you run them. I don't remember the cost, but it was a few hundred dollars for what he had to do and a lot of hoop jumping to get there.

Working on my lab today, it's been neglected for months and there are things I need to be testing (like these drivers) so tired of this situation where I have no time or ability to work on things I know I need in the future (like Server 2025).

dinhngtu

@Greg_E Do you mean autoupdate? It's not planned just yet, but you can update them with Group Policy using our guide here: https://docs.xcp-ng.org/guides/winpv-update/ (I think you don't need the Autoreboot setting any more, but it's worth testing). You can also use other tools like SCCM, PDQ etc. The drivers themselves are production-ready, and should not cause the domain controller issue on Server 2025.

As for getting the drivers signed, the certificate did cost some time and money, but the most difficult part is dealing with Microsoft (since we're signing drivers, we needed not just a certificate but also a Microsoft hardware vendor account).