Does your VM (using the same template) boot normally with any other Linux image, or if you started the agent from live CD?

@gck303 Were there any I/O drivers installed on your Server 2019 server? Do you have any events in the VM's System log, or any crash dumps?

I don't think you need the --unit declaration. Try serial --port=pci,0b:00.0 perhaps?

Preferably after, since the PV drivers contain some VM-specific settings that may be wiped by Sysprep.

You should look into using Sysprep, with it you can create a generalized template and specify domain join credentials for joining each new VM.

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)