@dinhngtu said in XCP-ng Windows PV tools announcements:
@probain The canonical way is to check the product_id instead https://docs.ansible.com/projects/ansible/latest/collections/ansible/windows/win_package_module.html#parameter-product_id The ProductCode changes every time a new version of XCP-ng Windows PV tools is released, and you can get it from each release's MSI:
No problem... If you ever decide to have the .exe-file as a separate item. Not bundled within the zip-file. Then I would be even happier. But until then, thanks for everything!
@Forza thanks. But as @normanghenderson a live migrate from 8.2 -> 8.3 didn't work for me either.
I tried that approach first, made the 8.3 to a new pool but it delivered some XCP API Errors ... which thinking of it now might have been a firewall issue but I manually checked access between the systems and everything seemed fine.
I now have everything running on 8.2. Have some non important VM on the new server that is 8.2 and will upgrade that one to 8.3 then see if I can migrate other VM away from the 8.2 systems.
If that works, I'm all good. If not ... I will have to start over from scratch.
But thanks everyone for the quick replies.
on another simpler install (One host, one XOA, no proxy, SMB remote in same lan not an S3 remote), XOA 5.112.1
same problem !
I think something has been broken along the way @bastien-nollet @florent
granular file restore is important for us, otherwise we have to get Veeam Agent backup instead of XO Backup
From another post I gathered that there is an auto-scan feature that run by default every 30 seconds which seems to cause a lot issue when the storage contains a lot of disks or you have a lot of storage.
It is not completely clear if this auto-scan feature is actually necessary and to some customers Vates helpdesk has suggested to reduce the frequency of the scan from 30 seconds to 2 minutes and that seems to have improved the overall experience.
The command would be this:
xe host-param-set other-config:auto-scan-interval=120 uuid=<Host UUID>
where UUID is the pool master UUID.
Of course I won't run that in production without Vates support re-assurance that doing so it won't have a negative impact but I think is worth mentioning this.
In my situation I can see how frequents scan would cause delay on the other tasks considering that effectively my system is always under scanning with probably the scan task itself being affected by it.
