working now after NIC driver update. Thanks

@olivierlambert said in XO Community Edition - Ldap Plugin not working ?: If there's no issue in XOA but XO from the source, it's very likely an environment problem, because we don't have any specific LDAP code difference between source and XOA. What exactly do you mean by this? I'm not a developer, so in almost all cases I defer to you - @olivierlambert - and the other knowledgeable members of the Vates team. However, in this case, I'm struggling to accept your logic. If by environment you're referring to the Active Directory configuration, then - at least - in my environment, that is the common denominator (i.e., the variable that hasn't changed). The fact that XOA works against the same AD domain but XOCE doesn't (unless a user's security groups are limited to no more than 2), hints to me that something is different in how the LDAP plugin is being implemented in XOA. Now, I didn't compile it myself but relied on @ronivay's install script, so it's very possible that perhaps there's something in how he compiles that's causing the issue - but I feel it important to emphasize that the AD environment hasn't changed - at least in my environment. I have other systems that are authenticating against the same AD backend, that I'm not having any issues with. If you guys can dedicate some time to troubleshooting this issue, I'm available to assist in any way possible (even if it means burning the midnight oil - just let me know).

@olivierlambert Thanks!

@payback007 said in vm start delay - does it work yet?: unfortunately "start delay" is not working as expected. The function what you marked above is to change the start delay of an existing "vApp". Here is an example of my setup: [image: 1558128450595-04e7439d-6b92-4356-aa23-14d704588be3-grafik.png] The value whould change the "Delay interval" later by XOA, nothing else. Otherwise is vApp feature also not working on my XCP-ng installation, I think it was never really tested. If you want to implement start delays to your VM's you can follow this guide: define vApp for autostart in xcp-ng center including start order find out the uuid of the vApp: xe appliance-list write autostart script containing #!/bin/sh xe appliance-start uuid=uuid-autostart-vApp implement new systemd.service in /etc/systemd/system/autostart.service [Unit] Description=autostart script for boot VM After=graphical.target [Service] Type=simple ExecStart=/path/to/your/autostart-script.sh TimeoutStartSec=0 [Install] WantedBy=default.target enable the service systemctl enable autostart.service Editing of boot delay time is then possible via XOA which is already a nice feature at all for "fine tuning" or adapt if new VMs are added to the autostart vApp. @olivierlambert whould it make sense to open an additional feature request? vApp-implementation was several times discussed with no "final statement" I think. When I have a pool without HA, how could I use this script? I thought about setting the script on the master server. However, in a maintenance, where a second node becomes the master, will I have to recreate the script?

Pareil, je n'étais pas au courant de cette limitation

@Mefosheez Marking a new post as a question will not be necessary. @anthonyper is the one working on what we think is the issue (a regression on the EDK2 package). I haven't heard of a fix yet, but it's in progress.

I will create a card for this feature request to discuss with the whole XO team. I will keep you updated here

The issue is in the VM indeed, it's not on XCP-ng nor XO. The VM doesn't cooperate because there's a problem inside it. Sadly, there's little we can do except to check if you don't use dynamic memory. Outside that, the OS is likely the issue.

@Davidj-0 From what I understand, the xcp host must already be turned on. The VM will only start at the defined time, when for some reason, it has been turned off previously. My plan was to have the servers power up when they received power. Then the "auto power on" XOCE VM would start and, via scheduling, power on other VMs in a predefined order. Does the "Appliances" feature only exist in the XCP-ng command line or in the XCP-ng Center? According to this link this feature does not exist on XO: https://xcp-ng.org/forum/topic/6311/managing-vapps-with-xoa

@Cygace XO is not directly tied to XCP. So the versions have nothing to do with each other. You can look at the XO master commits and pick one that lists feat: release 5.xxx.x and that will line up with a XOA release. You can pick a version that is the same as the current XOA release and it will be the same tested base code.

@rvreugde it is really strange... I only have one host on my setup that I'm using for testing and I don't see this behavior... But I see almost every minutes a message in my /var/log/xensource.log saying: Feb 10 14:55:58 xcp-gthvn1 xapi: [debug||518 HTTPS 10.1.0.100->:::80|host.call_plugin R:dd18d954e8e1|audit] Host.call_plugin host = 'd7f4a210-369a-410e-9c73-4acb59fe5e7c (xcp-gthvn1)'; plugin = 'updater.py' ; fn = 'check_update' args = [ 'hidden' ] I don't know who is calling this. But for me the file is always released properly. No process that locks the file... Not sure about what to test next. Is there someone on the forum with the same issue?

And of course there is the netdata plugin that can be enabled, https://xcp-ng.org/forum/topic/2288/netdata-package-is-now-available-in-xcp-ng Which will give you more performance metrics and health status.

@olivierlambert OK. I was guessing something like that. Many thanks for your answer. Best regards, BK

@Chico008 What does it show for the commit on the About page in XO?

@dvshmkr I think its a temporary glitch; I had the same issue but restarting toolstack solved it

Thanks, that's very useful info! @florent will take a look when he can!

This works fine, indeed. Thanks!