@dinhngtu Yeah, I suspected that as well. So I inspected the SR and it showed connected to both hosts (at least in the XO UI - I didn't drop to the CLI to really confirm). By altering my workflow a bit and slowing down, I seem to have found the right "sweet spot" of delay and the issue hasn't resurfaced. Here's what I'm doing now, when I need to revert the snapshots of all three VMs: In the XO VM list, I select the three VMs and power them off at the same time. I then start with VM1 and eject the ISO, VM2 and eject the ISO, then VM3 and eject the ISO. By the time I circle back to VM1 for the next step, about 10-15 secs have elapsed. I then start with VM1 and revert the snapshot, and repeat the same on VM2 and VM3. By the time I circle back to VM1 for the next step, another 10-15 secs have elapsed. I re-attach the ISO to all three VMs in sequence. Another 10-15 secs elapse. I then start with VM1 and power all three VMs sequentially. The entire workflow takes about 30-45 secs, and I'm finding that by doing this, the issue hasn't resurfaced.

@nikade more beautiful than scary, it goes in an usual place where no one lives as you can see on satellite view it's an effusive éruption, not explosive, i was barely 100m when taking photos and you can also poke lava with a stick if you want (but need appropriate masks because of harming gazes like sulfur) not the first time it goes to the sea, the island expands slowly no casualties except from some fishes

@Danp Thanks for looking into this... Restart: Yes, Pool Master was restarted after applying the XCP patches VM start: Yes, I'm trying to start the VMs on the master (also, it would not allow me to start VMs on the slaves with XenServer on it during the migration phase) Upgrade Path: Yes, vrom XS 7.1.2 to XCP 8.3 Regarding the VM_HOST_INCOMPATIBLE_VERSION: I saw those, too, but cannot think of anything obvious, as the VMs which I was able to start on the Master were of the same kind (WinSrv2019, Ubuntu Server, Win10). Of course, there might be slight differences in the metadata, but I've compared two WinSrv2019 and they are pretty close. Only "RW/MRW" differences found: HVM-boot-params (MRW): order: dc; firmware: bios HVM-boot-params (MRW): order: dc platform (MRW): ...; secureboot: false platform (MRW): ... I've removed those two param keys from the failing VM but it did not change the behaviour.

@dinhngtu You rock - thank you!