@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.

@lsouai-vates Duly noted.

If amd when you do get a moment, could you have a look at https://xcp-ng.org/forum/post/94297 and offer up any guidance on how I can stop the debug log entries and also the double timestamp entries in the audit.log file?

Thank you.

@ThasianXi Thanks, I will checkout the resources you've shared. I already figured out the XCP-ng side and wanted to get the XO side as well.

Thanks again.

@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.

Thanks to both of you, I adjust accordingly.

The strange thing is that, I have an open ticket and the way I've always corresponded with the team is by simply replying to that email and it's always gotten through. This is the first time I've seen that bounce (which suggests a change somewhere).

No worries though, I'll just log into the helpdesk portal and add a comment directly to the ticket.

@Chico008 Seems like you're duplicating your inquiries. As I suggested in the previous thread, I think your memberOf is missing the full DN of the group.

@Chico008 I suspect it's failing because memberOf must have the full Distinguished Name (DN) of the group, not just the group name.

@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.

@olivierlambert So XOA is running on local storage of host #1 (VMH01) and all the VMs run off an NFS datastore which I've checked and is not in read-only mode or full (has about 60% free space).

What I haven't checked is whether the partition being used as the Local SR on VMH01 is perhaps the culprit. I ran xe check yesterday and the only three things it complained about were NTP, Updates, and not having Internet connectivity.

I should be in the office in about an hour, so I'll inspect and report back.