@olivierlambert ok, is there a way we can keep an eye on this devepment? shall i open a feature request on this with support or what is the best way to proceed?
Best posts made by rtjdamen
-
RE: Why does the backup use snapshots and not CBT
-
RE: Why does the backup use snapshots and not CBT
@olivierlambert, yes, but the snapshot doesn't need to remain till the next job is running. This distinction significantly impacts space requirements. You don't back up all your VMs simultaneously.
-
Advise on pool
Hi, we are currently in the process of migration to xcp-ng, In VMWare we have multiple hosts running with different age and specs. I prefer putting these hosts into 1 pool. Currently we use hosts with these types of cpu's
First of all would it be possible to run these in a combined pool? second question is how to proceed, can we just put them all toghether and will the master manage the cpu masking? or is there one specific host we need to start with? I am curious if there is a manual on this proces? It seems that this is missing in the documentation.
What are your thoughts on this?
-
RE: Fetch VMS and there current hosts
@olivierlambert i will open a support ticket right away!
-
RE: Issues with diskperformance of an migrated vm
@olivierlambert i have now migrated 3 windows vms and they all perform well and normal.
Latest posts made by rtjdamen
-
RE: Why does the backup use snapshots and not CBT
Hi all,
Just an update on our progress, i have been doing backups for around 10 larger vms now on CBT, i have seen this is working pretty well but it is not the wonderfull solution we had in mind.
First of all, the Alike backup software we now use to make CBT backups does have issues with multi disk vms, for some reason now and then the CBT got disabled by XEN on one of the disks resulting in a new baseline that needs to be created the next day, this is causing higher and longer backup times, still workable but it seems there are still issues with CBT in XCP-NG, i can determine if this is an issue of the alike software or that this is being caused by XCP-Ng itself. I have currently no other backup solution using the CBT so we can’t compare the results there.
Also a new issue can occur, when u create a CBT snapshot during peak hours it can cause issues with coalesce as well, the snapshot is deleted and it has to be coalesced into the base disk, but when the vm is under higher i/o load it can cause an endless process of coalesce. This is basically a limitation of the XEN garbarge collection process but it is giving issues with backups from now and then.
From what i understand XOA is working on CBT as well, i believe some fundamental changes are needed to get this all working in the same way as it currently is in vmware and other products. I think it would be much better and much more reliable if this kind of coalesces are done direct at the vm level and not limited to 1 task per SR (as i understand there currenlty is).
I am curious if anybody else allready is doing tests with this and does have some feedback that could help us on this problems.
-
RE: Poor VM performance after migrating from VMWare to XCP-NG
@markds we have seen major improvement when booting a vm in uefi, for some reason vms created on vmware with bios are terrible slow on xcp-ng, switching to uefi made them running normal again.
-
RE: Why does the backup use snapshots and not CBT
@olivierlambert i have created a feature request for this over support.
in the meantime i will let u know the results with the current software we run, if this is working as required this can be a good addition for the environment document as well.
-
RE: Why does the backup use snapshots and not CBT
@olivierlambert ok, is there a way we can keep an eye on this devepment? shall i open a feature request on this with support or what is the best way to proceed?
-
RE: Why does the backup use snapshots and not CBT
@florent quadric currently keeps the snapshot as well but it only contains the cbt metadata, i believe very similar as we are currently running the backups with XOA
-
RE: Why does the backup use snapshots and not CBT
I wanted to share my first experiences so far, for 1 single disk vm it works perfect, cbt is created and left only for metadata till the next backup.
For vms with 2 disks i run into some strange behavior, after the bacup job is see one of the 2 disks snapshot (random) at the health page as not connected to a vm and when i run the backup job again it gives an error "source and target are unrelated", the orphan vdi section.
not shure if this is an issue on XCP side or on a bug inside there software.
as i cannot seem to reproduce this issue on single disk vm's i feel like this is an issue with multiple disks. i am contacting there support to see if this is a bug on there end or if this is an issue inside XCP itself.
Keep u all posted on the progess of this tests.
-
RE: Why does the backup use snapshots and not CBT
I have my configuration for quadricsoftware up and running, so far so good, works as promised. i will let it run for a few weeks and let u know the results. the CBT is a real game changer so far!
-
RE: Why does the backup use snapshots and not CBT
@olivierlambert ok i will share my experience as well.
-
RE: Why does the backup use snapshots and not CBT
@olivierlambert yes, maybe the documentation on xcp website can be updated to list them as well.
What is your experience with these backup tools, do u know of companies using them?
-
RE: Why does the backup use snapshots and not CBT
@olivierlambert i am currently looking at Quadric Software and storware, Quadric Software is doing the cbt backup exactly as needed, i got there description on the workflow yesterday
*When you run an ABD/hypervisor backup, the A3 will snapshot the VM for the duration of the backup data acquisition phase. After the datea is collected, the snapshot is immediately deleted.
In the case of CBT backups, the snapshot is deleted with the special XAPI command vdi-data-destroy, which frees data associated with the snapshot, but retains metadata, including the block allocation for the disk. This allows us to perform a delta backup the next time, with extremely negligible storage overhead.*
This is what we need