@cairoti, I think the VMs are restarted in their natural name order. I prefix mine with 00, 01, 10, 11, 20, 21, 22 etc., to control the start order.

Hi @KPS , The difference between these two settings is that sessionCookieValidity determines the time before a user gets disconnected if they did not check the "Remember me" option, and permanentCookieValidity determines this when this option was checked. If you want to force users to be disconnected after 12 hours regardless of how they connected, I think you need to set both sessionCookieValidity = '12 hours' and permanentCookieValidity = '12 hours'. However, this memory increase you're experiencing is intriguing, it is not an intended behaviour.

Warm migration is probably the safest bet in all circumstances because there's no CPU compatibility issues

@irtaza9 happy to help!

@Danp we have some cloud init ready templates like 5-10. We want only these templates on our pools. For now I want these templates to be shown in pooltest pool after that I will follow same to connect it with other pools. I have an NFS server and I saved these templates in that server on a specific path and now I want these on XO so that I can create VMs from these templates. I do not know how to configure further. Pl share any guide or tell me the steps so that I can achieve this. Thank you. I do not need ISO I will detach this NFS ISO library.

Hello, the Hub is offered as is. We'll update the available templates soon. In the meantime you can convert any VM to be a template. More here : https://docs.xen-orchestra.com/vm-templates

@irtaza9 AFAIK, that is how it is intended to function when using a cloud-init enabled template.

bump. Spent some time again to remember why backups don't work after migration.

@nathanael-h Dang, do any of you sleep?! This is pretty much what I need, and would actually significantly improve what I'm building! Will wait_for_ip be included? As well as the rest of the Terraform logic? But as you're building a Python script you could implements there the same logic: define a variable for your expected cidr, and poll the IP of the VM until it matches. Duhh, Why didn't I think of that . Thanks for the help!!

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

@Danp Thank you, I've updated to latest build and seems to have sorted it.

@DustinB Emergency Reset Worked. ty

@olivierlambert Well that was easy. Much appreciated!

@isdpcman-0 Which version are you running (XOA > Updates)? You can check the logs by connecting to the VM via SSH and then running the command journalctl -u xo-server -f -n 50.

Please open a support ticket, obviously for a large infrastructure that would be logical to be sure it's not behaving like that or to make sure XO disable things in the correct order before trying to evacuate a host

@olivierlambert do you know who on XOA side can have a look?

working now after NIC driver update. Thanks

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.

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.