@gawlo if you can reboot then you can try, but if the process is started after the reboot, it will still block your mountpoint.
And the mountpoint is the result of this command
xe pbd-param-get param-name=device-config uuid=44e9e1b7-5a7e-8e95-c5f1-edeebbc6863c
@technot when you say performance was a bit on the low end when dom0 handled the drive, how low compared to when the controller is passthrough?
For ZFS, it is still good with few number of disks but the performance won't be high than raid10 until you have more vdevs (which means striping across multiple vdevs). You do need to passthrough the disks to dom0, so you'll have to destroy the raid as you mentioned and the more ram the better for ZFS, usually around 1GB per 1TB of storage for good caching performance.
One thing to note, you can't use ZFS for dom0 yet so you still need another drive for XCP-ng.
@gawlo to check mountpoint as olivier suggested
lsof +D /mountpoint
@gawlo have you try restarting the host? may be check if xapi service is running
systemctl status xapi.service
Machine type? Are you talking about QEMU stuff? If so that is only for emulation, XCP-ng is virtualization so you get the same hardware in your VM as the physical hardware on your host.
You can use the following command to display all the PCI devices being passthrough, and then just set them up again without the one you want to remove.
/opt/xensource/libexec/xen-cmdline --get-dom0 xen-pciback.hide
@Vinylrider your understanding is correct, delta retention is just how many deltas to keep before merging the oldest delta with the full. Full backup interval is the time between each new full back up for use in case of corrupted back up.
To answer your question, yes it is recommended to have more than 1 full back up to fall back to in the event of corruption espcially of delta backups since delta backups rely on previous deltas meaning if one of your delta is corrupted, you'll loose all data from that point onward until another full backup is made, or worse your full backup could be corrupted (more likely because of the file size) then you loose the whole chain. And if your corrupted delta is merged with the full, you'll probably have a corrupted chain aswell.
@stevezemlicka are you using XO from sources? It looks like permission issue when creating local mount point, have you granted access to the user?
@Rocky most like a connection issue, but since you already restarted I think the logs are already gone. If it was a one-off I wouldn't worry about it (but do make sure that the backup is actually working, may be a good idea to do another full backup).
@Rocky was it a one-off or has happened many times?
@gawlo if you can reboot then you can try, but if the process is started after the reboot, it will still block your mountpoint.
And the mountpoint is the result of this command
xe pbd-param-get param-name=device-config uuid=44e9e1b7-5a7e-8e95-c5f1-edeebbc6863c
I am not sure, may be one of the devs can answer that question.
@pnunn you can use this command to check for which vdh you need for a specific VM
xe vbd-list vm-uuid=<vm-uuid>
Look in the vdi-uuid, if it is <not in database> that means it is probably a snapshot, ie. not connected.
Use this to check for vm-uuid if you're not sure
xe vm-list
@technot when you say performance was a bit on the low end when dom0 handled the drive, how low compared to when the controller is passthrough?
For ZFS, it is still good with few number of disks but the performance won't be high than raid10 until you have more vdevs (which means striping across multiple vdevs). You do need to passthrough the disks to dom0, so you'll have to destroy the raid as you mentioned and the more ram the better for ZFS, usually around 1GB per 1TB of storage for good caching performance.
One thing to note, you can't use ZFS for dom0 yet so you still need another drive for XCP-ng.
@gawlo to check mountpoint as olivier suggested
lsof +D /mountpoint
@Denson so if you don't add this host back to the pool it doesn't go read-only? May be it has something to do with shared storage, anything in /var/log/SMlog? Also check
df -h
@gawlo have you try restarting the host? may be check if xapi service is running
systemctl status xapi.service
@kevstone122 some on-board USB controller use PCIe as the interconnect so you can still use PCI passthrough with on-board controller, depends on the motherboard. If your USB controller is listed when doing lspci then you have a good chance.