@olivierlambert I was able to sort out the issue, it has to do with licensing and the fact that we aren't licensed to with "Live Migration" for this ESXi host.
Essentially this inquiry is solved.
@olivierlambert I was able to sort out the issue, it has to do with licensing and the fact that we aren't licensed to with "Live Migration" for this ESXi host.
Essentially this inquiry is solved.
@TechGrips While I can understand the desire to use removable USB as a Backup Repo, I would highly discourage it.
Managing and rotating USB drives is a pain, if they go to sleep, it's a pain, if they fail it's a pain, if you forget to rotate your drives, it's a pain.
I personally can understand the desire to do so, it's cheap and relatively affective if you can deal with these risks, however so is just using any NFS or SMB share and then having a replication script that could write to your USB, which you could then rotate. Separating your XCP-ng hosts, XO, and your backups is of critical importance because if you have any sort of server room environmental issues or failure, you're risking loosing everything.
XCP-ng and Xen Orchestra, while they do offer a ton of flexibility, there is obviously trades-offs to using less than ideal components, such as external USB drives as your primary backup repository.
If you really want to insist on using USB drives, you'll have to attach the drives to your host and then pass them through to your XO installation, which when you want to rotate those drives you'll have to update your Backup jobs within XO and confirm that your XO VM has the proper access to the drives. This seems like a lot of complexity for very little financial benefit.
Separately I think you're taking your own frustrations out on the community, because of a lack of understanding in the tooling that you testing in comparison to ESXi where you'd attach a USB drive directly, perform your backup, remove the disk and attach another.
I get that ESXi can make things "simple" but simple isn't always better.
HTH
The reason you wouldn't want to look at XO for this from a technical standpoint is because XO works at the hardware level of the hypervisor, dolling out resources to different VMs and creating backups.
You need to look at the content within a given VM and compare the file system difference from points A and B.
Only something that is operating within the file system would be able to readily tell you "Something has changed".
Odds are you have a user or several who are dumping files onto a share that they shouldn't be, or are replicating some cloud service to keep a copy on your server etc.
If I had my choice, Prevent Migration is more understandable.
Disable Migration, while it means the same thing, doesn't naturally come out of the English language.
@flakpyro said in How to migrate XOA itself?:
@DustinB Are the any downsides to having two XOA instances pointing at the same pool? Since the config itself is stored at the pool level im guessing theres no downside?
IE: Priimary XOA running in core DC and secondary XOA running at your DR site. Is it just a matter of adding the pool on the secondary XOA and it downloads the existing config or did you need to do a full export / import?
If you import your configuration, each XO instance will think they should be running the backups as far as I've noticed. If I have two instances running with the same configuration, I simply disable the backup jobs on one of them.
The config file is just an XML that contains your existing instance. You can import it to any new XO instance and have the same exact configuration.
@olivierlambert I agree wholeheartedly with you on that. Keeping the system stock is best for support.
Separately, is there any planned work on officially integrating support for Uninterruptable Power Supplies and XCP-ng 8.3?
A question
You can disable all of the boot devices in the Advanced section of the VM, try disabling the HDD
Disable the Boot options if your system is making it past POST to quickly so you can get into the Guests BIOS.
@jasonnix said in A question for the creators of XO:
Hi @olivierlambert,
No, I'm not a bot. I asked it because I need your experiences. I want to make a panel for Xen.
So you know how to program with PHP and Ruby and not with Javascript, so the question is really "Why can't this be rewritten so I can help?"
For laughs I am testing with a VM that is powered off and its going, albeit slowly (likely due to a 10FDx port on the ESXi host).
@Danp said in Run a script inside guest OS from host:
@ajpri1998 What about using something like
psexec
or
the powershell commandInvoke-Command
?
Exactly what I was going to recommend, but the request is to be sent from XCP-ng (the hypervisor) rather than some management server..
What would the Windows PowerShell command be doing within the VM, that resides on XCP-ng?
and
Why does the hypervisor need to issue the command to the VM?
@Shrubbery said in xcp-ng 8.3 not recognizing all host memory:
The issue was memory reserved for the integrated graphics card
haha.. that is such a silly thing... but good to know then next time I'm working on some hardware and wondering where the RAM is going too...
@flakpyro said in Manual snapshots retention:
@olivierlambert I wonder if it would be beneficial to show all snapshots older than 30 days not just ones not created by an automated process. For example what happens if a XO backup job runs, creates a snapshot but the process is interrupted and the job fails. Will the next time the job runs clean up the previous failed jobs snapshot or is there a chance a snapshot could be left behind?
Garbage collection should be handling this...
@olivierlambert I added a response in the hopes that it clarifies the end-goal.
@Tristis-Oris said in XO tasks - select all button:
@olivierlambert i remember news, but it never works for me(
Are you using XOA or XO from Source?
@manilx said in Manual snapshots retention:
@Tristis-Oris To be honest, this just opens more "configurations/complications" for a fringe case.....
Manual backups should never be deleted, unless I specifically do that (in an enterprise environment you don't necessarily know why they were made but there certainly was a reason fir them).An information in the dashboard for backups "older" than x days could be interesting, yes.
Right, I think having just a list of Snapshots older then X (that aren't created from a scheduled job) would be beneficial to validate that things aren't getting too long in the tooth.
@CodeMercenary Do you mind sending me your serial number, I'd be happy to take a look for you to confirm.
If you don't want any jobs running in parallel at all, you would set your concurrency to 1 (or maybe 0) so that only a singular VM would be completely backed up at a given time, but this will certainly break the "Start my Backups at 01:00".
Because your backup jobs are starting at 01:00 for the first VM chosen, but your last VM might not start it's backup until 23:00 the following day depending on your system and network performance...
@cgasser here is an article on it that @olivierlambert wrote some time ago, https://xen-orchestra.com/blog/xen-orchestra-backup-concurrency/
Basically you have to set your concurrency to be lower than the default limit of 2 per the documentation. https://docs.xen-orchestra.com/backups#backup-concurrency
@cgasser I believe this was discussed in another thread, but to summarize you should set your job-concurrency, otherwise it defaults to something like 4 jobs at once.
But even in that scenario, not every job is going to run at 01:00 because some job would be waiting until the last job has completed, offsetting your start time of the next job.
@Shrubbery If you check BIOS do you see the full 16GB of ram, and does this box have a built in memtest that you can validate that the memory isn't faulty?