Posts made by dinhngtu

With 9.0.9000.0, you could sometimes run into this issue if you reboot too early after installing. This will also be fixed in the next release.

Hi, this is a known issue with the testsign enable script. It only affects silent installation (e.g. by using msiexec /quiet); normal driver installation (by double-clicking the MSI file) will run normally. I'll fix this in the next release. In the meantime, you could use the following command to install the certificate manually:

certutil -addstore -f TrustedPublisher XCP-ng_Test_Signer.crt

Did you choose Use SSL in Ldp.exe? Either your AD SSL certificate is misconfigured or something is blocking connection from your Linux host.

How did you issue LDAPS certificates to your domain controller? Do you get the correct certificate when doing openssl s_client -connect ad-server.domain.ar:636 ?

What about ldapsearch from Linux: LDAPTLS_REQCERT=never ldapsearch -H ldaps://ad-server.domain.ar -x -D xo_ad@domain.ar -w ... -b 'OU=Usuarios,DC=domain,DC=AR' -s sub ? This should give the correct query output.

The exact configuration as yours worked fine in my environment. What happens when you try to search LDAP manually with Ldp.exe?

How did you specify your auth-ldap settings (URI, bind credentials, search parameters)? It worked for me when I used the URI ldaps://your-domain-controller-fqdn.

After some testing, I've found that running any service that creates a form (of which Xen management agent is one) will trigger the issue. This points to an issue in Windows Server itself rather than the Xen guest agent.

I've created a thread on Microsoft Community to keep track of the issue: https://answers.microsoft.com/en-us/windowserver/forum/server_performance-servertop_application/creating-an-ui-autostart-service-on-a-server-2025/c2ced91b-21c2-49c1-86a6-24b90dc72c6d. In the meantime, please use @Greg_E's method of setting the Xen management agent service to delayed start to work around this issue.

I'm investigating further.

Could you collect a crash dump using a boot CD?

Could you try it again with a fresh 2016 VM? I'll try to reproduce the issue.

You should put your root CA in a file accessible on the XO VM (e.g. /usr/local/share/ca-certificates/ad-root.crt. Point the CA setting to this part and enable "Check certificate". You must use a service account for binding.

You can use the following command:

yum localinstall xen-{dom0-libs,dom0-tools,hypervisor,libs,tools}-4.17.5-4.0.lbr.19.xcpng8.3.x86_64.rpm

Please try the RPMs first, they contain the fixes that we'd like to integrate with Xen upstream. Also please note that you need to reboot the host after installing these patches.

I think it's a compatibility problem with newer Intel CPUs. We have some experimental patches available. Do you have an identical host for testing purposes? Could you install the following RPMs and see if it helps?

https://nextcloud.vates.fr/index.php/s/MYZpPgQCRwWnDYq

If you don't want to install test RPMs you could try the following command instead:

xe vm-param-add uuid=... param-name=platform msr-relaxed=true

Could you describe the hardware being used?

You can redirect its serial port to a TCP port on the host (xe vm-param-add uuid=<uuid> param-name=platform hvm_serial=tcp::7001,server,nodelay,nowait) then connect a Windbg remote kernel debugger using a connection string (com:ipport=7001,port=192.168.1.xx)

Try \Windows\MEMORY.DMP?

Does it boot into recovery or Safe Mode at all? If nothing works, you can pull the crash dump with a Linux live CD, then analyze it on your own Windows machine.

Nested virtualization has some compatibility issues. Could you analyze the crash dump with Windbg and see what it says?

Personally a PowerShell module for XO sounds more interesting. (No promises though)

It's a known issue with the new Citrix drivers: https://support.citrix.com/s/article/CTX235403-updates-to-xenserver-vm-tools-for-windows-for-xenserver-and-citrix-hypervisor?language=en_US

It shouldn't happen again in future updates.