Hi, Looks like we've got a similar problem on our newly deployed XOA (5.103.1). There are approx. 500 tasks and some of them are "refreshing/changing places in the list". Also, next to the "Tasks" button on the left inventory menu we can see "1" from time to time (screenshot: 03.PNG). Haven't yet tried to clear it but would first understand why this is happening and maybe it can be perma fixed? 01 [image: 1742913684189-01.png] 02 [image: 1742913690478-02.png] 03 [image: 1742913697611-03.png]

@DustinB Yeah, that's what I will try to remember to do next time. This is still worlds easier for me than trying to keep my ESXi hosts up to date was back when I used them. So very much better than that. I very rarely updated those at all.

@djp I am not really sure what else besides migration traffic passes over that .

@Forza There are various topics touching on how SMAPIv1 is a bottleneck here, eg: https://xcp-ng.org/forum/topic/9389/backup-migration-performance/8 - that's probably not the best example as it is also more on backups than migration!

Hi, If you have support, you should create a ticket asking for the feature if you need. We don't have much request for that, but if nobody ask, it will never happen by chance If you don't, you can still open an issue on our XCP-ng repo to ask for it, at least we'll have a trace of the request

@john.manning Happy to hear that. I guess it was my fault - I edited the naming of the snipped pseudo vars: OLDVBDUUID = xe vdi-param-get uuid=VDIUUID param-name=vbd-uuids VDIUSERDEVICE = xe vbd-param-get param-name=userdevice uuid=OLDVBDUUID maybe that way it's clearer for others that might find that helpful

@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