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 .

You should have kept on thread, it's easier to track. Anyway, another ping to @pdonias

Question for @pdonias when he's back

@gduperrey Awesome news - thanks for quick reply.

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

Likely easier by using the REST API I suppose. Let me ping @MathieuRA for example

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.