As I can't find it anywhere: What exactly is happening on join/leave? Is the masking changing at runtime and affecting every new started VM, does the pool need to be rebooted after an older server has been removed, to "unlock" all features? I have a pool with HPE DL380 Gen 9 and 10 where Gen 9 will replaced with Gen 12. So I assume it makes sense to remove 9 first, then add 12. But how exactly is the masking process working? Should I reboot Gen 10 first (shutting down all VMs) or add 12, move VMs over... or just shutdown and start all currently running VMs? In the early days (~XenServer 6) it had to be done manually by getting CPU features, calculating the commons and give it as parameter to join command. What I did not see though, is: How exactly is it working on removal and what's best practice. (also: should be added to documentations)

Great job, worked perfectly! Thank you very much for your fast support!

Hi @McHenry . You should obfuscate the IP address in your first screenshot. Also check your profile and private chat Hope everyone had a joyful Christmas and I wish everyone the best for 2026. Regards, Marc

Thanks @olivierlambert , really appreciate quick help. VM migrated successfully.

some timeout or race condition between the end of the job and the mail generation ? perhaps putting 10sec delay to send mail ?

@zeropointer @numo68 I have added my script back seeing so many people might require a solution. I'll try and improve it as and when required.

Not until we can have our own piece of code doing it. Right now, it's a binary that's not Open Source made by Citrix, we cannot legally re-distribute it.

@olivierlambert Thank you. I thought maybe I was losing my mind/eye sight, especially after reading that google search indicating there was a start button in 6.

@Danp said in VDI not showing in XO 5 from Source.: xe vdi-param-list uuid= Hi Dan, [18:52 mycsskvdcxcp03 ~]# xe vdi-param-list uuid=5f899e22-f3a7-4f0b-8de6-2b8058c0f575 uuid ( RO) : 5f899e22-f3a7-4f0b-8de6-2b8058c0f575 name-label ( RW): ADSIM-UAT_DISK01 name-description ( RW): is-a-snapshot ( RO): false snapshot-of ( RO): d31f2db0-be21-4794-b858-1bea357869c8 snapshots ( RO): snapshot-time ( RO): 19700101T00:00:00Z allowed-operations (SRO): clone; snapshot current-operations (SRO): sr-uuid ( RO): 5d22cba7-fbf6-a03b-bb73-9ffba3a3ee75 sr-name-label ( RO): SR-HDD-DEV-2 vbd-uuids (SRO): c6f4c7fa-4f6f-7999-d13c-3a29d887d828 crashdump-uuids (SRO): virtual-size ( RO): 171798691840 physical-utilisation ( RO): 50272698880 location ( RO): 5f899e22-f3a7-4f0b-8de6-2b8058c0f575 type ( RO): User sharable ( RO): false read-only ( RO): false storage-lock ( RO): false managed ( RO): true parent ( RO) [DEPRECATED]: <not in database> missing ( RO): false is-tools-iso ( RO): false other-config (MRW): xenstore-data (MRO): sm-config (MRO): host_OpaqueRef:c3426081-ce96-507b-a219-8d2cb124c3ad: RW; read-caching-enabled-on-e1594701-28e9-4127-858e-74d4663669f8: true on-boot ( RW): persist allow-caching ( RW): false metadata-latest ( RO): false metadata-of-pool ( RO): <not in database> tags (SRW): cbt-enabled ( RO): false [18:54 mycsskvdcxcp03 ~]# Best regards, Azren

That worked; thank you!!!

I just learned something new, thats awesome

Ping @team-xo-backend

Thank you guys! Problem temporarily fixed by Vates support,

not better with production upgraded to 6.0.1 (XOA and XO Proxies) we will open a support ticket ps : if we delog/relog from XOA with another user, we have better chance to get the file restore working... not 100% very unstable is there a link ?!

Ah indeed, labels are honored even in the case of a warm migration. We used it ourselves when we migrated from Intel to AMD CPUs, it was really the best compromise betweeen live and cold (especially when you change the CPU vendor). Glad to see it's helping many people and companies now

Excellent news

@McHenry Turning off the Manage via Windows update first + tools uninstall + reinstall should take care of it.

@dinhngtu I believe it was changing the guest TSC Mode that seems to have done the trick.