@taghjichte XOA stands for xen orchestra appliance (@olivierlambert correct me if i am wrong), this is different then xo lite. U can deploy a xoa instance from xo lite, it gives u a 30 days free trail version. Left u have the import function and choose for vm, there u are able to import an ova file.

Hi All,

I try to run grafana queries against the XOA Api, i created a json api connection and add header Cookie with “authenticationToken={apikey}” the validation is succesfull. When running a query with get \vms againt the api i get 0 results. I am doing something wrong as a test with curl gives me a lot of results. Anyone been doing this before on XOA and Grafana? Maybe someone can put me in the right direction?

Cheers Robin

@taghjichte is there a reason why u do not use the buildin feature of xoa for migration? For us this worked on all our vms.

@flakpyro good that the root cause is found, hope it is something that can be fixed by the xoa team.

I can confirm that the cbt backups are running as smooth as they did on vmware! Good job all!

@florent so this does mean it will never work when a forever incremental is used?

We are further testing with immutability and have encountered a question that came to mind. Suppose you run a 14-day backup, merging your oldest delta into the full backup every day. If you're doing forever incremental, the oldest file will keep being modified. This means that either this file becomes immutable for another 14 days after each merge, or it remains editable after 14 days, rendering immutability ineffective. How do you handle this in your setup?

@olivierlambert my pleasure, good to be a part of it.

Good news, this bug seems to be resolved!

Hope we can fix the migration bug as well!

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

@flakpyro very strange issue indeed, we can’t reproduce the problem on our end. So as @olivierlambert mentioned before it has to be something specific. The new developments make it indeed more difficult to understand, but i believe there is a logical explanation to this.

@florent Goodmorning,

We have prepared the script here https://github.com/Virtual-Computing-bv/Xen-Orchestra-Immutability-SYNOLOGY

Would it be possible for you to do a check on this script to see if u have any comments?

@florent thanks for the feedback, so if i understand correct, currenlty there can only be one retention be used, if u use a retention of 14 days and 30 days mixed, u can only set immutablity for 13 days, otherwise you would run into issues with merge?

maybe this is something we can think a better solution for in future versions. we will implement your comments into the script and test it on our lab. If it's working we will share the code.

@olivierlambert we have managed to get this working on a synology box. However i have some question regarding the first setup.

1. the file is locked for x days (let's say 14 days), it will then work for a backup of 14 day retention, what to do if u have different retentions per job? there is no way for the repository to know this. what theorie do you have for this?
2. someone with root access does still have the option to change the files is this a good idea?
3. this immutability is also for meta files in the repo, is this not an issues? in other words the repository meta files can's be changed for 14 days as well.

Hope u can give me some answers so we can proceed working on this feature.

@Tristis-Oris indeed seems like thats a bug in xoa that it does not delete the snapshots

@Tristis-Oris migration of a vdi between sr is not supported with cbt enabled. U need to disable cbt first. This is done by xoa. Live migration of vm between hosts is supported as long as the sr stays the same. This is by design on xen

Hi all,

we are trying to deploy a new kubernetes cluster, in the recipe i need to give an ssh key, we generated an ssh key with puttygen and copied the content of the openssh public key field. however this seems to not work. it failes with an error on the deployment of the first control vm after setting the key. What am i doing wrong? what do i need to set in the ssh key field?

cheers Robin

@olivierlambert we are starting to develop the synology version this week. I will ask my developer to contact you or support if he has any questions.

@DustinB thanks all, the agent based backups seem to work the way we need, we removed the older alike backup appliances so fully on xoa backup now. I saw alike is going opensource but almost no activity on the github account, i expect that the product will discontinue as it is allready pretty outdated, nice chance for XOA to fill the gap.

@Rhodderz ok so it’s not only related to v8.3 as we were assuming. Or somerhing else is going on in your env. What happens if u use normal backup without cbt?

@Rhodderz are u also on 8.3?

@olivierlambert for now we will go with Nakivo as we allready have a good experience with them, i will explore te agent based backups there to see if they can help to improve the backups of these vms. thanks again for the prompt response!