Control domain of Xcp-ng
-
Would be great to know the purpose of the control domain.It looks its related to the snapshot. Want to know more details on this .
-
@sumansaha When you do a backup the snapshot needs to be downloaded by Xen orchestra, for that this snapshot is first exposed by your dom0 through an http link, that's what's VDI attached to the control domain means. They are snapshot attached to your dom0 VM to be exposed through http.
-
@Darkbeldin is it safe to forget the control domain from
Dashboard-> Health->VDIs attached to Control Domain -
@sumansaha Not forget the control domain but yes you can remove the VDI attached to it.
-
@Darkbeldin There is no other to remove VDI. Do you mean to remove the VM.
-
@sumansahabd No what you are seeing in Dashboard > Health are VDI attached to your dom0 not dom0 himself so yes click on the item there and remove them it's ok.
-
Actually I didn't get you . But the two control domain snapshot has two base copies and consumed storage space. Please suggest how we can remove the control domain snapshots.
-
It's not a control domain snapshot, it's a VM snapshot (Porta web) MOUNTED on the dom0.
Having a snap mounted to the dom0 is OK during the backup phase, but if it's still attached after, it's not normal.
So if it's outside a backup, you can disconnected the snapshots from the control domain, remove the VM snapshot, and then it should be coalesced automatically
-
I've disconnected the snapshots and after that should I go for to Destroy VDI' .
-
Check if your VM with porta web doesn't have a snapshot, that will automatically remove all the snapshot disks
-
There is no snapshot actually. Should I run "Destroy VDI" on the snapshots from the disk.
-
Yes, destroy the VDI snapshot in the SR/disk view
-
Thanks for your response.After 'Destory VDI' from Disk currently there is only one base copy. And no coalesced process running now. Is there any way to remove current base copy.
-
No. If it's not coalesced automatically, there's a reason
-
@olivierlambert How we can troubleshoot that.
-
https://xcp-ng.org/docs/troubleshooting.html is a good start to read.
In your case, it's likely inside
/var/log/SMlog