@yeopil21 you can target vsphere it should work The issue here is that XO fail to link one of your datastore to the datacenter is it XO from source or a XOA ? you should have in your server logs something like can't find datacenter for datastore with the datacenters and the datastore name as detected by XO are you using an admin account on vsphere or is it a limited one ?

@florent, I had to do the same for Xen Orchestra Community Edition. In my case, config.toml already contained the [authentication] section, so adding a separate config.tokenValidity.toml file did not work. Instead, I had to modify the existing config.toml located at /opt/xo/xo-server. In my opinion, it is best to keep defaultTokenValidity set to 30 days as a fallback in case no value is specified. You can then simply increase maxTokenValidity to the duration you prefer. [authentication] defaultTokenValidity = '30 days' # default value of 0.5 years # comment out and increase to 5 years #maxTokenValidity = ' 0.5 year' maxTokenValidity = '5 year'

@yeopil21 Run top, xentop, and iostat to see if dom0 and.or the storage device might be a bottleneck. The configuration of your storage device can also be a big factor, and in some casaes, various performance tweaks are possible. The specific configuration would be helpful: connectivity (NFS, fibre channel, iSCSI), number and size and speeds of disks, RAID configuration, total number of VMs resident on the device, number of independent SRs, provisioning (thin or thick), network (if not fibre channel) speed and settings. STorage optimization is a bit of an art and in many cases, can be the limiting factor, but as stated, so can the lack of dom0 resources. Also, what clock speed and number of CPUs are on your hosts?