@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
The 2nd option is basically forcing the static IP through XCP-ng, if you have SSH access to your XOA VM then you can also use option 3 (hint: XOA is based on debian 10).
The steps for option 2 are:
xe vif-list vm-uuid=<UUID of your XOA VM>
xe vif-configure-ipv4 uuid=<UUID of your XOA VM VIF> mode=static address=<IP address/Subnet mask> gateway=<Gateway address>
There is so much you can do through a web browser, I think your best bet is to click SSH or SSH as... to open up putty instead.
While we're at it, most CPU icons have "legs" on 4 sides, and RAM icons have "legs" on 2 sides, the current CPU icon looks like RAM chips instead 
@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.
Seems to be working now with commit c0d20, thank you.
Sorry @olivierlambert I just updated a couple of days ago and thought I was on latest, I'll update again and recheck. Thank you.
I just notice the encryption textbox at the bottom, I don't have anything filled in, could this be the issue?
Hi,
I've been using pool metadata backup for a while now without problem, but for the past month it just won't work. I am not sure whether it is related to new updates or not but did update XOCE to the latest git commit 84e38 and the problem persist.
The backup job failed after a few seconds with the below error:
Error: timeout while getting the remote 32cb6a61-ac0c-4f40-a8ea-d99b5291747d
I checked the remote page and ran health check, which seems fine.
I even tried ssh into the XOCE VM and check /run/xo-server/mounts/32cb6a61-ac0c-4f40-a8ea-d99b5291747d and I can see all the files there.
I tried deleting the remote and recreating it, no luck. I tried deleting the backup job and recreating it, no luck. I tried deleting xo-config-backups and xo-pool-metadata-backups to let it try to start fresh, also no luck.
Note that I have 2 backups, only metadata one failed, the normal VM backup seems to be fine, using the same remote.
What am I missing here?
Thanks,
Tony
@ninghe Are A and B identical servers? No shared storage? Does it work if you use normal snapshot mode?
@toby4213 said in GPU passthrough - Windows VM doesn't boot correctly:
This is the only GPU installed on the system, no integrated graphics(Ryzen 5 3600). This shouldn't be a problem right?
I had this problem before and XCP-ng won't boot without another graphic card to display its xsconsole. It might have been changed in latest version of XCP-ng but if not you'll have to have at least 1 graphics card for the host (can even be an iGPU) and another PCIe card for the VM.
Also support for GeForce graphics card for VM is still in BETA stage so it might not work 100%, if you want to be sure then try your GRID card which might work better. AMD cards will work for sure even with vGPU.
I do not get this problem on XCP-ng 8.1, just to add more information.
@techjeff So network permission is probably not the cause, but I'm still not sure why it hasn't worked right out of the box. Did you ever try replicating before setting up the NIC bonding? I only asked because your MAC address (FE:FF:FF:FF:FF:FF) is a bit weird. Also another thing you can try is delta backup instead of replication, just to see if that goes through.
@kdm I'm not sure which settings are you referring to? If you mean the Allowed IPs then no, that setting is to be used in conjunction with VIF-locking mode.
@techjeff It seems that the transfer stopped (interrupted) immediately after it started, the snapshot went fine. Can you try to login into XOCE shell and transfer something to the back up remote mounts manually?