Hi All,

are there other users running 8.3 combined with CBT backups? we keep running into vdi's that stay connected to the control domain, we are investigating these with Vates as it looks like the problem is within xapi of tapdisk it would be helpfull to understand if there are others running into the same issue.

As far as i understand from vates it looks like the problem we face is somewhere within Xapi but we need more logging to understand it better. If anyone has this running with the same issues or without please let us know so we can compare.

Cheers!

Hi All,

First of all best wished to you all for 2025! I have just deployed the latest build to do some testing on the one remaining issue we have with cbt backups, we were still facing full backups on some vms, this is expected to happen because cbt is not activated fast enough on some vdi’s, i will update this post once it completed some test runs to let u know if this build resolves it (there is a fix inside this build that should fix it).

Robin

@andyh no cbt should be disabled, u can’t migrate an cbt enabled vdi.

You need to remove all snapshots before migration and disable cbt. Storage migration is not supported when cbt is invalid. I believe xoa should do this automatically however.

@florent ok thanks, but how does this work for a job with multiple retentions? if i have a job with 3 schedules and retentions set for this job, how does the sequence handle this, in other words as the retention is set on the schedule level and i disable 1 of 3 schedules, how does the sequence know what retention it should keep?

@Andrew we see the same behavior here, no strange backup issues so far!

Hi all, i can confirm the vdi_in_use error is resolved by https://github.com/vatesfr/xen-orchestra/pull/7960 we no longer see issues there.

Only remaining issue we see is the “ can’t create a stream from a metadata vdi fall back to base”

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed feat(backups/CBT): retry data_destroy when error is VDI_IN USE #7960

@olivierlambert i have changed it to V3 and it feels like it is performing normally now. i need to do some more testing but it seems the synology does handle the read/writes better on V3 then V4.

@olivierlambert yes i will check this out as well. The mirror job itself seems to perform well, i changed the nfs to V3 as a first test for now, i read there is more overhead on V4, maybe this will improve things a bit. I will share the results!

@manilx nope, but i have talked with a dev about it and they are looking to make it a setting somewhere, don’t know the status of that. Good to see this works for you!

@jshiells i believe this is by design for a mirror backup. it checks every vm to mirror (if no filter is selected that will be all on the SR), if there is no new recovery point it will not copy anything as it allready does have the latest version of that backup on the destination recovery point. When a filter is selected it checks every vm on the sr but it does not copy data.

@Bzyk47 you would need a second host to do live migration/import. What u can do if u can affort any downtime is export your vms to ova of vmdk and rhe install xcp-ng on your vmware host and the import the vms. Its not possible to upgrade vmware to xcp-ng with the vms on it.

@Bzyk47 This is relative easy, you install XCP-ng on your office host, install Xen Orchestra, migrate your vms. On your home location you can do 2 things.

1. create a remote nfs share where Xen Ochetra can do vm backups to.
2. Create a local XCP-ng installation where you replicate the vms to.

Both is fairly easy to deal with from within the standard settings in Xen Orchestra. The amount of data changed a day is only important for the slow connection in between for replication. i use 500mbit connections for this and that works pretty fast.

If u need anything else or need assistance with the setup just let me know!

@Andrw0830 yeah shure, from dashboard u have the health tab, there u find vdi attached to control domain, we gave random vdi’s that stay attached. Although it seems to be random so we are investigating if this is an infeastructure thing or a bug. In xapi. We did not face this on 8.2.

We do not have issues with cbt after creating and then removing snapshots.

@Andrw0830 so just to confirm, you also have random vdi’s that stay connected to control domain?

The issue with the migration network is a known onee i understand from vates and is currently being worked on.

Hi All,

are there other users running 8.3 combined with CBT backups? we keep running into vdi's that stay connected to the control domain, we are investigating these with Vates as it looks like the problem is within xapi of tapdisk it would be helpfull to understand if there are others running into the same issue.

As far as i understand from vates it looks like the problem we face is somewhere within Xapi but we need more logging to understand it better. If anyone has this running with the same issues or without please let us know so we can compare.

Cheers!

@MathieuRA thx, i will test this, would it be doable to create a button on the backup tab of a vm in xoa to initiate the backup for that specific vm? Couldn’t be that difficult

@Cygace as far as i know xcp-ng in general is open-source and works the same as the paid version. The paid version does only apply to support and maintenance based on the Xen Orchestra Appliance XOA which is a paid product. However you can run XOA from sources with the same functionality as the paid version. The only thing u will miss is the support from the Vates Team, i believe in a production environment it's always preferable to run paid support but for testing purpose i see no reason why not to start with the unpaid versions.

@olivierlambert in a failed job the button is allready there so i shouldn't be that difficult to show it somewhere else or on a finished job. That last one is not so difficult i guess and is fine for me.

Hi All,

When a backup job is failed u can restart the backup for one specific vm in that job, currently this button is missing in a job that went succesfully, in some cases it could be very usefull if u can rerun the backup only for that specific vm and not for the whole job. in case u need an extra backup for the vm or in my case when the cbt of that vm is corrupted and needs to rerun to get it fixed. Is there any way to force run the backup for the one vm instead of the whole job? maybe an api call?

Cheers Robin