@olivierlambert Ah, ok...thanks, but I'm not using the appliance; I installed XO via source.

Hi, Can you describe exactly the steps you are doing? And from which client (XO UI, CLI, API, xe?)

Hi @olympicgreg, this seems to be the intended behaviour. Self Service and ACLs weren't designed to work together, so when you create a VM, you either do it under the Self Service feature or thanks to the ACLs you have. So in your case, the user might have Viewer ACLs on the pool, but since they create the VM using Self Service, they will only be able to see the resources available in the Self Service resource set. Regarding ACLs, "Viewer" is not enough to be able to create a VM on the pool. But if you change it to "Admin", you'll see that the user is now able to create a VM outside of the Self Service feature, simply by selecting the pool. And in that case, they'll be able to see all the pool's networks.

@nuentes For reference, the “PCI Passthrough” that was referenced involves buying a USB PCI card, and passing the card through. If you need any help getting the script up, just respond here and I’ll do what I can to help. My comments in the script arent immaculate

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

Also post VGA being disabled, it does seem better.

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.