@kagbasi-ngc I figured out what the problem was, so wanted to post it for the benefit of the community.

The root cause for me ended up being a firewall issue on the Windows Server where I was running the NFS server role. While I hadn't made any changes to the firewall, the profile of the network interface connected to the management network had changed from Domain to Public/Private, thus, Windows Defender Firewall applied the most restrictive settings since it saw that the NIC wasn't connected to the Domain profile (even though it physically was).

This post on Serverfault (https://serverfault.com/a/647201/189248) clued me in and I looked at the Network Location Awareness service (NLA). It was set automatic and was running, so I restarted it and this reverted the profile of the NIC back to Domain and caused Windows Defender Firewall to apply the previously configured rules.

It is important to note that this situation won't be common, as most of you won't be running your NAS on a dual-homed domain controller that is also running the DHCP server role. Hope this helps someone.

@Prilly Looks like @lawrencesystems has a good explainer video on YouTube at https://youtu.be/weVoKm8kDb4?si=QH93rOKaXLglrIbS

Check it out when you get a chance, thanks.

@nathanael-h Yeah, I've already done that several times and no luck.

What I'm gonna try now is see if I can boot it with the Windows installation disk, go into recovery and access the WinPE command line, and see if I can run xenbootfix.exe to clean out the guest tools/drivers.

If that doesn't work, I'll just blow away the VM and start over. I just hate doing this, cos it doesn't give us the chance to figure out why this happened.

@olivierlambert Cool, I'll run the other two when I get back. I'll kick them off simultaneously.

@olivierlambert No sir, I have not. I'll try that and report back shortly.

@anthonyper said in Imported VM Starts but Does Not Initialize the Display:

yum update --enablerepo=xcp-ng-aperard1 edk2

YES - you fixed it! Thank you!!!
I tried the package and it worked - the VM started and was able to initialize the display and finish booting up. Glad you found the issue and I'm even more glad that it was my report that prompted you to look into this. This is a true testament to the power of this community.

@stormi Sorry for the delayed reply. I did as you requested, and below are the resulting log files. I started the VM at timestamp Dec 17 14:43:34 and stopped it about 2 minutes later.

• daemon.log
• xensource.log

If I can be of assistance, don't hesitate to ask please. Thank you.

@olivierlambert No, it's the other way around. Once the subject user is a memberof 3 or more groups, the problem occurs.

@manilx Yeah, not doing it in production, just in a test environment. Plus I only did it because I actually found a write-up by the Vates team on how to get it done, which confirmed to me that while they don't recommend it for production, they understand that it has some merit in a testing environment and want to see it working.

That said, I definitely hear your admonition and would never do it in a production setting.

@olivierlambert Certainly strange, then, that the same settings and same plugin works in XOA but not in XOCE. We could argue perhaps some configuration variances within the Domain Controllers, but given that I'm the same person that configured both environments - I'm highly confident that I stood up the DCs in the same way. Only things that would obviously be different would be the Domain Name and OU Structure.

I'll confirm the Forest and Domain functional levels later this evening and perhaps run an XOA trial and see if it works. I'll report back.

@john.c Thanks for the suggestion - I'm exploring this option.

@Davidj-0 Thanks for the admonition. I was more concerned about the single point of failure that seems to be inherent with the plugin only allowing a single LDAP/AD server to be specified. As I mentioned to @pdonias , most of our environments (and in my lab) are setup with at least 2 domain controllers, where the Windows systems already leverage them natively.

For the Linux systems we have, which are integrated into AD using SSSD, there's the DNS lookups that happen which essentially protects against the kind of failure I experienced in the lab (where someone accidentally disabled the NIC on the DC that happened to be configured in the LDAP Plugin in XO). Even though the DC was still reachable over it's management interface, authentication into XO was now broken until I discovered it.

@pdonias Essentially, yes.

Every application I've used that authenticates with AD/LDAP seems to allow the specification of at least two servers, so that if the first doesn't respond, the second is tried. In almost all the environments that I work in, there are at least two Domain Controllers. So it stands to reason, at least to me, that XO should give the administrator the choice of deciding whether to leverage all DCs or a single one.

Normally the current implementation hasn't been a problem, until it was. I noticed this when one of my network guys accidentally disabled the NIC on the DC while attempting to add a management interface to the DC. Grant it, this is a lab environment and we're playing around a lot, but I thought this exercise highlighted a single point of failure so wanted to inquire if it were possible to specify more than one server.

Thanks for your response, much appreciated.

Good-day Folks,

Is it possible to specify more than one server when configuring the LDAP plug-in in Xen Orchestra?

I have two Active Directory Domain Controllers that I would like to specify, for redundancy. I've been meeting to ask this question for a while, but it kept escaping my mind.

@ph7 Yep, that's what I've done. Actually, I've powered off the prior XOA instance. Not ideal, but a workable solution.

@Bastien-Nollet Thanks for the update. In my community edition instance at my church, I just updated it to Master, commit 37fbb so I'll test over the weekend and provide an update.

For my XOA (Airgapped) instance at work, I did receive an updated appliance about two weeks ago, so I'll test and see if the problem persists. If it does, then I'll just wait until the official release of XO and then I'll request an updated appliance.

@DustinB Yeah, my thoughts exactly. Would be nice if XO supported logging to a remote syslog server, like XCP-ng does.

I haven't done this yet, but I'm gonna go through /var/log and see if perhaps those logs that are visible in the UI are actually being written to disk. If so, then I could just ship them off and import them into the new appliance.

@DustinB Yep, that's precisely what I did (which went very smoothly, by the way, with the exception of a few plugins which didn't startup automatically so had to start them), then discovered, the config + metadata backup does not include the appliance logs and audit logs - so my security folks are on me about that.

I have a ticket into support now inquiring into what the best approach would be to move these two logs from one appliance to another.

@lawrencesystems Yes sir I agree, as that is my experience with XOCE. But with XOA (Airgapped), in my PoC Lab, I've received my first upgrade and it was a completely new appliance. So I'm now figuring out how to handle that. I did reach out to Vates support about this and got a response that they are looking into perhaps doing the XO updates kinda like how they handle it now for XCP-ng (i.e., allow us to download the entire repo offline and then do the upgrade that way).

I'm sure you've dealt with many customers who are in my kind of environment, where security/compliance requirements are strict.

@lawrencesystems Makes sense.

I always assumed that since XOA was delivered as a service, that one had to leave the settings as-is. Good to know that they allow customization. But for an air-gapped environment, that presents some challenges for when upgrade time comes, and a new appliance is delivered. One has to remember to put the customizations in place on the new appliance before cutting to it. Not a deal breaker, just an annoyance factor I guess...lol.

Thanks again for chiming in.