@cocoon hello! For now we are on reflexion on a refactoring to move towards a system more RBAK based, IAM type. We will inform the whole community when we are sure of the direction the new ACL system will take. Stay tuned

removed the failed server connection. Restarted xo-server service. Added new host again. Seems fine now. In hind sight, I could have very well recycled a DHCP ip here as well, if that is a known issue...

Sounds a like a bug to me, we can maybe check what's displayed in there and take a look at xe level to see what's the problem Ping @lsouai-vates

@olivierlambert deploying fresh copy worked and registered under different email. Thank you for assistance

Great, thank you!

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

This page is being improved as we speak It shouldn't be in "Future improvements" because it's here

Excellent news, thanks!

Sorry I don't see any error, it's just a message from the GC. However, I have to admit I don't have time to take a deeper look myself. If you have support, might be the right time to open a ticket, alternatively someone will take a look when they can

@Danp yes I ran "yum update" to be sure but "nothing to upgrade" on the pool-master. I try with storage (iscsi) NIC configured and without Storage NIC configured but the pool join freeze. Seems that persist some "SESSION" (may be referred to the slave host previously configured?) or some incoerence in the pool database... from /var/log/xensource of the slave host when try to join the pool: "session_check D:520c5b4e5b36 failed with exception Server_error(SESSION_INVALID, "

@dinhngtu Thanks and good point. After my previous post I did stumble across some info (can't find the links) that suggested something similar. If I'm remembering correctly, the basic idea was the flash/NVRAM memory on the motherboard, which stores boot entries, is limited. If it's full, it's possible / may be necessary to do some cleanup using the bios itself or utilities available for Linux (efibootmgr) and Windows (bcdedit). I've not tried this myself as our install is working properly, but perhaps that can help someone else in the event they stumble across this particular issue.

Ahh excellent news! Thanks for keeping us posted

@yeopil21 I would add a file config.tokenValidity.toml in /etc/xo-server with this content [authentication] defaultTokenValidity = '1 year' maxTokenValidity = '1 year'

@dmz0001 In theory, XCP-ng 8.3 is mostly on par with XenServer 8.4, it's only a naming thing that they did as their previous naming was confusing some of their customers. Long story short, XCP-ng ~= XenServer 8.4. So what you see in the compatibility list of XenServer 8.4 is the right reference for XCP-ng 8.3. Unfortunately we do not have much feedback on Zen 5 at this time on our side.

Indeed, you are right and it's about to be fixed very soon. Thanks!

@Pierre-Briec You can try something like Mailjet.

@olivierlambert This is great, thanks for letting us know! I'll give this a shot in my lab as soon as I can.

@olivierlambert xe vdi-forget uuid=c6853f48-4b06-4c34-9707-b68f9054e6fc xe sr-scan uuid=6b24cd1c-22ad-0994-5b6b-a75389a6ddba xe vdi-list uuid=c6853f48-4b06-4c34-9707-b68f9054e6fc params=sr-uuid sr-uuid ( RO) : 6b24cd1c-22ad-0994-5b6b-a75389a6ddba yup, that worked, thanks

Excellent news! Thanks for keeping us posted