Did it for you 🙂

Hi, I've noticed the addition of the commit about the 99 limit warning. That's good news.

I am now having trouble trying to understand the meaning of the Full Backup Interval setting.

I have the following scenario:

Backups for the last 30 days, daily. Backups for the last 52 weeks, weekly. I want to make sure that the delta backups are not corrupt periodically (let's say once a month).

I don't understand how to set the schedules, the backup retention, the full backup interval.

I also need answers to the following questions, and I haven't been able to understand this from the documention.

Do I need one delta backup with 2 schedules, or 2 backups with one schedule each ? I've noticed that full backup interval is per backup, whereas retention is per schedule. How do these two settings interact with multiple schedules? On what dates will the transfers be large ? How many full backups will be stored on the remote at any given time ? When will the merges happen?

Thanks

https://xen-orchestra.com/docs/community.html

Always pull the latest commit and rebuild before opening a thread 🙂

Hi,

Have you checked that before? https://xen-orchestra.com/docs/community.html

Do you get any errors that would help?
You might only need to add the user correctly in

/etc/sudoers

@segfaultex a patch release will come this month fixing a condition preventing correct migration.

THank you.
Its up and running nothing broke 🙂

No problem, happy to help 🙂

@MichaelCropper, to answer your question, yes, I enabled networking during the installation process. This allowed me to SSH in following the subsequent reboot to run yum groupinstall "Workstation". VGA was enabled for me and then Video RAM was at 16MiB. @ben20ben brings up good advice with the XCP-ng tools, install it and life gets easier.

Thanks for the feedback 🙂

@olivierlambert said in suggestions for future upgrade...:

web hooks

Thank @olivierlambert

I'm going to read about web hooks in xoa. 👍

The idea is to give the best visibility to your plugin 🙂

Though I don't think we'll ship it directly to our customer because it's an advanced use case 😉

Nevermind. I don't know what I did, but eventually, the host was listed a halted and a Forget option was available. That did the trick.

FWIW, this issue was likely due to using an outdated version of Node. The script is being updated to detect this scenario.

Hard to tell. If it happens again, try immediately to compare XO behavior with other clients to see if we can tell where is the problem 🙂

This is probably a snapshot created to be able to coalesce by the system (when the VM is up). Try to shutdown the VM, I'm pretty sure it will coalesce without needing another snapshot.

Because I want to push users through a web portal interface which can obtain information from XO-Server for presentation back (ie: VM status, parameters, etc) whilst also allowing users to start/restart/shutdown VMs.

We looked at XOA however it was too expensive and the free version has nag text messages which I don't want presented to users.

Hi,

Thanks for picture update, I will fix it 🙂

Thank you again! This did the magic trick.