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

@kagbasi-ngc You are welcome.

@kagbasi-ngc said in VM Console Screen Suddenly Inaccessible: Hmm, interesting observation about potentially this being a failed migration issue. I can confirm that none of my users in the lab are migrating any VMs or this particular one, for that matter. However, I do have the Load Balancer plugin running and it could be the source of a migration that could've failed. How can I confirm this in the logs? I mean, what should I be looking for? While trying to find logs, you can try to find the VM in question and see if it is using local storage rather than shared.

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.

Hi, Thanks for your report. Ideally, move XOA VM on another SR than the one doing the maintenance mode. Alternatively, you can do it manually with the CLI or XO Lite. You raised a valid question: XOA should have detected it was itself on the target SR and prevent it. However, even if it sounds simple, it might not be trivial. Anyway, I'm adding @lsouai-vates in the loop so we can improve this in the future

@Danp No sir, I have not. I have, however, exported the same VM in the OVA format. Ended up being about 47 GiB, however, I was able to import it into XOA without any issues, and the import took just under 10 minutes to complete.

@kagbasi-ngc said in Using Multiple Servers in LDAP Plug-in: @john.c Thanks for the suggestion - I'm exploring this option. Oh, forgot a bit of follow up. You can also do something similar with Linux. Using the clustering software configured for failover and also a Samba server. The Samba server needs to be at minimum version 4.0, though to be supported with updates version 4.20 at minimum, to guarantee a long period of support either 4.21 or 4.22. Though using the in box Samba server from RHEL 9 is best as its supported by Red Hat and is version 4.15. Though you can select another Linux distribution which is new enough to support at minimum the same version of Samba. Then run the process of setting up the Samba Server as an Active Directory Domain Controller. https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller Also with Windows Server based solution, you can add more servers to the AD Failover Cluster as required. So effectively you could even have 3-5 AD domain controllers, instead of just the 2 AD Controllers for redundancy.

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

@olivierlambert Aah, you got me there. Thanks for all the support thus far, really appreciate it.

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

@ecoutinho Thanks for chiming in. I managed to figure out the math, but thanks nonetheless.

@DustinB Hmm, hadn't thought of that one. I'll try it and see.

@olivierlambert said in VM Failing to Reboot: Quick check: is hardening is done via any MS virtualization technology? If yes, it could be a nested virt problem maybe (just throwing ideas) Certainly could be. @dinhngtu said in VM Failing to Reboot: @kagbasi-ngc Could you apply the hardening controls now and see if the VM still works? Yeah, I'll try doing that today to see what happens. We generally get an already hardened ISO from our upstream Security Team, so as to minimize the deployment time. However, I can manually harden myself - although, since it may not be the exact same process as followed by the upstream team, there's a chance I will not be testing apples-to-apples.

@olivierlambert Yes we can, however, it's unsettling not knowing the root cause. But seems that restarting the Xen Toolstack may have resolved this issue. I haven't attempted creating a VM yet, so I'll do that when I get in tomorrow.

@olivierlambert Technically, yes, I suppose I could do that. However, that would not mimic what a SysAdmin would have to do, should they run into this trouble in production. Is there no other alternative to get this utility, perhaps as a .deb package that I can manually install on XOA? Lastly, I performed the following testing just now: Created a new VDI on a known working VM and put the VDI on the problematic SR (let's call it NFS-DS1). I then attempted to migrate the newly created VDI to the known good SR (NFS-DS2); it failed with error VM_LACKS_FEATURE. So I crested another VDI, attached to the same VM, but this time I put it on SR NFS-DS2 (the good one) and then attempted to migrate it to SR NFS-DS21; IT WORKED. So I retried migrating it back to NFS-DS2, and it worked as well. Finally, I went back to the original new VDI I started with, and attempted to migrate it from SR NFS-DS21 to NFS-DS2; it worked! SO, it seems the issue remains with the VDIs that seem to have lost their parent. P.S. I haven't noticed the VDIs disappearing from SR NFS-DS1 for over an hour now.

@olivierlambert Thanks, for at least acknowledging that I'm not crazy. I'm willing to help out with testing, just let me know what's needed of me. I'm not a developer by any stretch of the imagination, but I am a seasoned SysAdmin with just enough Linux knowledge to be a little dangerous...lol.

@olivierlambert You're most welcome. XCP-ng + Xen Orchestra is a solid solution and I would very much like to see it get adopted within my organization, so I'll do anything (legal of course) to work through these problems and share the solutions, so the entire community can benefit.

@olivierlambert Awesome! Can't wait.