@cbaguzman it will read only the allocated blocks of the delta , so it should be quite fast, depending on how full is this disk delta

Hey @Andrew, thanks very much for looking that up and providing the suggestions! Re. option 2: it's possible to just hide the T600 from dom0 and remove the R9 270 from the machine? dom0 won't complain that it's missing a GPU, or take control of the only GPU in the system?

@shorian ova export is here to ensure compatibility with other systems, but is far more brittle (and slow) than xva export For a regular export, I would really advise to use xva export if it's possible to make it work with your use case.

@Danp To answer your earlier question about the state of the patched hosts, three hosts are currently fully patched with one of them as the current pool master. I've tried to promote both of the other two with the same "Cannot restore" error. For the sake of completeness I just tried promoting one of the non-patched hosts. Same error. And I'm still unable to deploy a new VM ("NOT_SUPPORTED_DURING_UPGRADE").

Yes but why it works with some and not others. I suspect the firmware version in the NIC itself.

@Bastien-Nollet okay i'll do that tonight and will report back

As an observation ; I'm going to draw attention to @majorp93's point about rebooting the servers after ALL nodes have been upgraded. Historically we would move all VMs off master, upgrade master, restart its toolstack, then reboot master, then move VMs from Node 1 to master so we could begin the upgrade on Node1. Normally works ok but last time around it caused all sorts of problems. Previously it had felt right to upgrade master in its entirety including the reboot before moving on to the next host and rinse, repeat - but this cost us a lot of time, corruptions and pain. TLDR: Perhaps add a footnote to the docs that when upgrading a pool the reboots should take place as a final step across the pool only after all nodes have been updated.

@fcgo if the storage is shared : the export is done by one of the host of the pool If the storage is not the export is done by the host with the storage . Same for the host receiving the data The command channel, as you said, is always the master to the xoa (and eventually xo-proxy) So for a replication : [source SR] => source host =https export call=> xoa / xo-proxy =https import call=> target host => [target SR] if the xoa is running on the host doing an export, it does not use the physical network the network use between the host and SR is dependent on the storage used