@tjkreidl said: @john.c Most interesting, and I fully agree, that a strong host model enforcement policy is really the best and only recourse for such a topology, or so it would seem. The only other option that comes to mind would be to not put the heartbeat connection on any sort of bond or multipath. That's, of course, not ideal. I’d need to source additional single 1 port NIC both of my pool host servers, as I’ve used up almost all of my 24 port managed switch Netgear GS724Tv4. It would also need to be compatible with my Dell PowerEdge R620 servers.

@poddingue Thanks for taking a look. Yes it is this part that tells me that it should start the VM automatically once the import has completed. "After the transfer, the VM on XCP-ng side is started:" Followed by, "This process is fully automated, without any human intervention after it starts on step 1." [image: image.jpeg] https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/ But my findings/experience is that the VM does not start once the import/transfer has completed. So either the docs are wrong. Or the function is not behaving as intended. I'm acctually fine either way. As long as I know what to expect. However, I would like to have it auto-start the VMs after transfer completion. Which would make the procedure "Fully automated". Update: Am I assuming correctly that "the XO V2V guide says to start the VM yourself once the migration is complete " you're reffering to, is part of the "test migration"-procedure? Not the acctual production mgiration? Because: "Final migration Run the production migration When you're ready for the final migration: Shut down the source VM completely. Start the V2V migration in Xen Orchestra with the Stop source option enabled. This ensures the final sync happens while the VM is powered off, and prevents any inconsistencies." In my mind doesn't state that the VM should be started manually post-transfer. Great thanks in advance for discussing! Cheers!

@ronan-a For testing purposes, I did the following: I created a VM on the local SR of a host, installed Linux on it, and configured an ISCSI target. I then added that ISCSI target as an ISCSI SR within xcp-ng pool, and created a small VM on that repository, using XO. While the machine was running, I performed a migration without losing a single ping.I assume this confirms my previous assertion regarding the use of a standard storage system.

Thanks, @Jonathon !

@Jonathon if I read your xen02 output right, from before the resync it already had 0 out of sync towards both other nodes, so the big number only ever lived between xen01 and xen05. After invalidate-remote both of them are copying fully from xen02 (that's the SyncSource and Inconsistent lines in your last post). I don't know whether that secondary-to-secondary figure comes back on its own once the resync is done. If it does, the date it reappears and roughly what that k8s worker was doing at the time are probably what @Team-Storage would want to see. I'm curious too, so please do post how it looks after a few days.

Hi @henri9813, from what I can read in the XO source, that log line is only informational right now. The code that finds those folders logs "you could delete orphan VDI directory", but the actual removal is still a TODO, so nothing gets cleaned on the remote automatically (here's the spot). My guess, and I haven't checked what the Health delete button calls exactly, is that it removes the backup metadata and counts on that same cleanup to take the disk folders away. That would explain why the space never comes back. I don't know whether it's safe to remove those vdis/... folders by hand, so I'd rather not tell you to rm anything. Might be worth a mention to @Team-XO-Backend, they'll know if there's a supported way to clear them.