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.

@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.

@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.

@yzgulec there really isn't any hard-fast rules to aligning CPU to vCPU. A Guest is going to need cores to operate no matter what.

If you're trying to min-max your CPU utilization for a given system, you might want to target the guest to use between 70-80% of it's vCPU all of the time.

This is all a part of system tuning and is always a shifting target, as CPU is shared among all VMs and DOM0.

As you increase the number of guests on a host, the CPU consumption will be increased, which means you may need to scale back on the vCPU a given VM has.

@stormi said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

Do others share this feeling and have this question after re-reading the whole announcement?

No it's pretty clear, update the drivers on everything as all versions are susceptible.

@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

• Have you clicked into the console screen before hitting F12?

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?"

@GuillaumeHullin said in RPM package vmfs6-tools missing for local migration procedure:

/centos/cert/7/x86_64/vmfs6-tools-0.2.1-1.el7.x86_64.rpm

The documentation references a RPM package that was torn down by the provider.... and for a very old distro.

So that part of the documentation needs to be updated.

@olivierlambert said in Can't boot a VM with 1TB memory / 128 CPUs:

We are testing some machines with 6TiB RAM

My god

I can't even imagine how long a memtest would take on a box with this much ram. Ha

@techjeff Correct, I am an active user of the forums

@peo said in Backups started to fail again (overall status: failure, but both snapshot and transfer returns success):

@olivierlambert Thanks, will update every machine and XO involved in the backup process, and possibly even the individual machines that fails. First failure on vm-cleanup was 15 July, that's a few days before I patched the hosts (as a part of troubleshooting and preventing further failures). Still these backups will (probably) be fully restorable (as I have tested out with the always-failing Docker vm)

So you patch your host, but not the administrative tools for the hosts?

Seems a little cart before the horse there, no?

@HH said in XO Commuity Edition Xen Orchestra, commit fee7b geht nicht auf Master, commit e5702:

I didn't mean that I want to go to 6.0 now, but when 6.0 becomes "Stable LTS", get that automatically with your script ?

Assuming there aren't any major changes to the upgrading processing using the existing script should work, but that has to be determined once a general release is created.

@HH Just follow the documented steps in the updater github, since 6.0 hasn't been fully released yet there isn't anything special to it.

@HH said in XO Commuity Edition Xen Orchestra, commit fee7b geht nicht auf Master, commit e5702:

udo curl https://raw.githubusercontent.com/Jarli01/xenorchestra_updater/master/xo-update.sh | bash -s -- -n stable

correct, this will put you on the "stable" release of XO from Source.

sudo curl https://raw.githubusercontent.com/Jarli01/xenorchestra_updater/master/xo-update.sh | bash

Would work for a properly running instance, but you may have changed at some point to "next-release"

@HH said in XO Commuity Edition Xen Orchestra, commit fee7b geht nicht auf Master, commit e5702:

@DustinB said in XO Commuity Edition Xen Orchestra, commit fee7b geht nicht auf Master, commit e5702:

journalctl -u xo-server -f -n 50

Weisst du was das bedeutet:
Jul 22 08:45:47 as-xoce xo-server[887]: at process.callbackTrampoline (node:internal/async_hooks:130:17)
Jul 22 08:45:47 as-xoce xo-server[887]: }
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.714Z xo:plugin INFO successfully register auth-ldap
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.714Z xo:plugin INFO successfully register auth-github
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.714Z xo:plugin INFO successfully register auth-google
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.715Z xo:plugin INFO successfully register auth-saml
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.715Z xo:plugin INFO successfully register auth-oidc
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.715Z xo:plugin INFO successfully register netbox
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.715Z xo:plugin INFO successfully register transport-icinga2
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.715Z xo:plugin INFO successfully register test-plugin
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.715Z xo:plugin INFO successfully register transport-nagios
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.715Z xo:plugin INFO successfully register transport-slack
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.715Z xo:plugin INFO successfully register backup-reports
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.715Z xo:plugin INFO successfully register load-balancer
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.715Z xo:plugin INFO successfully register transport-email
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.734Z xo:plugin INFO successfully register audit
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.734Z xo:plugin INFO successfully register perf-alert
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.734Z xo:plugin INFO successfully register transport-xmpp
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.734Z xo:plugin INFO successfully register web-hooks
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.749Z xo:plugin INFO successfully register usage-report
Jul 22 08:45:47 as-xoce xo-server[887]: 2025-07-22T08:45:47.861Z xo:plugin INFO successfully register sdn-controller
Jul 22 09:03:45 as-xoce xo-server[887]: (node:887) [DEP0044] DeprecationWarning: The util.isArray API is deprecated. Please use Array.isArray() instead.
Jul 22 09:03:45 as-xoce xo-server[887]: (Use node --trace-deprecation ... to show where the warning was created)
Jul 22 09:03:45 as-xoce xo-server[887]: 2025-07-22T09:03:45.700Z xo:xo-server WARN Node warning {
Jul 22 09:03:45 as-xoce xo-server[887]: error: DeprecationWarning: The util.isArray API is deprecated. Please use Array.isArray() instead.
Jul 22 09:03:45 as-xoce xo-server[887]: at IncomingMessage.flash (/opt/xen-orchestra/node_modules/connect-flash/lib/flash.js:67:16)
Jul 22 09:03:45 as-xoce xo-server[887]: at file:///opt/xen-orchestra/packages/xo-server/src/index.mjs:322:11
Jul 22 09:03:45 as-xoce xo-server[887]: at Layer.handle [as handle_request] (/opt/xen-orchestra/node_modules/express/lib/router/layer.js:95:5)
Jul 22 09:03:45 as-xoce xo-server[887]: at trim_prefix (/opt/xen-orchestra/node_modules/express/lib/router/index.js:328:13)
Jul 22 09:03:45 as-xoce xo-server[887]: at /opt/xen-orchestra/node_modules/express/lib/router/index.js:286:9
Jul 22 09:03:45 as-xoce xo-server[887]: at Function.process_params (/opt/xen-orchestra/node_modules/express/lib/router/index.js:346:12)
Jul 22 09:03:45 as-xoce xo-server[887]: at next (/opt/xen-orchestra/node_modules/express/lib/router/index.js:280:10)
Jul 22 09:03:45 as-xoce xo-server[887]: at Xo._handleHttpRequest (file:///opt/xen-orchestra/packages/xo-server/src/xo.mjs:173:7)
Jul 22 09:03:45 as-xoce xo-server[887]: at Layer.handle [as handle_request] (/opt/xen-orchestra/node_modules/express/lib/router/layer.js:95:5)
Jul 22 09:03:45 as-xoce xo-server[887]: at trim_prefix (/opt/xen-orchestra/node_modules/express/lib/router/index.js:328:13)
Jul 22 09:03:45 as-xoce xo-server[887]: at /opt/xen-orchestra/node_modules/express/lib/router/index.js:286:9
Jul 22 09:03:45 as-xoce xo-server[887]: at Function.process_params (/opt/xen-orchestra/node_modules/express/lib/router/index.js:346:12)
Jul 22 09:03:45 as-xoce xo-server[887]: at next (/opt/xen-orchestra/node_modules/express/lib/router/index.js:280:10)
Jul 22 09:03:45 as-xoce xo-server[887]: at initialize (/opt/xen-orchestra/node_modules/passport/lib/middleware/initialize.js:98:5)
Jul 22 09:03:45 as-xoce xo-server[887]: at Layer.handle [as handle_request] (/opt/xen-orchestra/node_modules/express/lib/router/layer.js:95:5)
Jul 22 09:03:45 as-xoce xo-server[887]: at trim_prefix (/opt/xen-orchestra/node_modules/express/lib/router/index.js:328:13)
Jul 22 09:03:45 as-xoce xo-server[887]: at /opt/xen-orchestra/node_modules/express/lib/router/index.js:286:9
Jul 22 09:03:45 as-xoce xo-server[887]: at Function.process_params (/opt/xen-orchestra/node_modules/express/lib/router/index.js:346:12)
Jul 22 09:03:45 as-xoce xo-server[887]: at next (/opt/xen-orchestra/node_modules/express/lib/router/index.js:280:10)
Jul 22 09:03:45 as-xoce xo-server[887]: at urlencodedParser (/opt/xen-orchestra/node_modules/body-parser/lib/types/urlencoded.js:94:7)
Jul 22 09:03:45 as-xoce xo-server[887]: at Layer.handle [as handle_request] (/opt/xen-orchestra/node_modules/express/lib/router/layer.js:95:5)
Jul 22 09:03:45 as-xoce xo-server[887]: at trim_prefix (/opt/xen-orchestra/node_modules/express/lib/router/index.js:328:13) {
Jul 22 09:03:45 as-xoce xo-server[887]: code: 'DEP0044'
Jul 22 09:03:45 as-xoce xo-server[887]: }
Jul 22 09:03:45 as-xoce xo-server[887]: }

Nothing appears to be wrong here

@HH said in XO Commuity Edition Xen Orchestra, commit fee7b geht nicht auf Master, commit e5702:

Current commit a9789ba6301f60ab839b2329bcd95c15d1989649 2025-07-22 10:09:54 +0200
Switching to branch 'next-release'...
No stash entries found.

I'm assuming you're using the "Stable" branch, but maybe not. Take a look at my github on how to check what channel to be on.

@HH said in XO Commuity Edition Xen Orchestra, commit fee7b geht nicht auf Master, commit e5702:

Is this really due to my server?

Possibly....

@HH It might be worth checking the logs, journalctl -u xo-server -f -n 50

If nothing stands out still, you can always export your configuration file for XOCE, build a new installation on a new VM and import the configuration.

For what it's worth, I don't see anything standing out with what has been provided.