Forum XCP NG

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.

@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!

I wasn't even aware about this being a Windows limitation by itself

@samuelolavo Hello, Could the fact that this is a local LVM SR on a non-master host be relevant to how make_chain_rw is being handled? Yes, it's indeed what's happening. The check for the SRMaster (for a shared SR it's the master but for a local it's supposed to be done on the host directly) is failing and always saying False. I'll fix this. Thank you for the help

From what I read in the docs (HA isn't my strong suit), a host in an HA pool that loses its heartbeat in certain ways is designed to reboot itself, which they call self-fencing, so this may well be HA doing its job rather than something crashing. The log you attached is from the master and starts at 11:21:00, and dacshyp001 is already marked as not live in the very first liveset at 11:21:08, so I think whatever triggered it happened just before that and isn't in this file. The three Setting host dacshyp001 to dead lines look to me like one event being re-checked every 20 seconds while 001 was still coming back, though I could be misreading that. I also suspect 003 went down at a different moment, because it still shows as alive in that same liveset. There's a doc section for this case, https://docs.xcp-ng.org/troubleshooting/troubleshooting-ha#my-host-rebooted-why-did-it-reboot, which points at /var/log/xha.log on the host that rebooted. Could you post that file from dacshyp001 and dacshyp003 for the few minutes before each reboot, plus 003's boot time?

@abudef asked almost exactly this a few days ago over on 12466, and @pierrebrunet answered it there with a link to the doc describing the layout, so that thread's probably your quickest route. For the specific "which VM is this folder" question, the UUID in the directory name is the VM's own UUID, so xe vm-list uuid= params=name-label on a host should give you the name back. One thing that bite me when I tried it: if the VM has since been deleted, that command prints nothing at all and still exits cleanly, so silence means "no such VM here" rather than "the command didn't work". Those silent ones are probably where your space has gone, if I had to guess. I'm not the backup expert here so someone may well have a tidier way of doing it.

@Emmanuel-V In my opinion, it would make more sense if a standalone disk exported in VMDK format were exported directly as monolithicSparse, so that it would not need to be converted. This makes more sense to me because when only the disk is exported, rather than the entire VM (OVA), it can be assumed that the disk will be attached directly to some VM.

I do have active directory setup in my lab environment. I just need to set aside some time to try it out between two domain joined hosts. Thanks for trying that! That's some good debugging.