Becomes a bit of a guessing game with these details, but let's go. Can you see any slowness anywhere else with the former one? Eq. SSH to the VM that runs XO works quickly, VM listing etc in the XO UI is fast and just the stats tab is slow? Anyway, based on the symptoms i'd first check that the DNS settings on the VM are working properly and there isn't for example a non-working resolver in /etc/resolv.conf that could timeout.

How did you install your XO from sources? Manually following the docs or using some 3rd party script?

Anyway the error kinda gives a hint "only root can use...", so you're running XO with a non privileged user right? Did you define useSudo configuration option and add proper sudoers configuration as the documentation suggests? That error comes directly from OS's mount command so you either need to run the process as root (which you're not doing properly if you get this error) or add the config option to use sudo when mounting remotes.

That script has a shebang pointing to node (first line), so no need to define it separately, just execute the script directly.

Sure. @Ascar the executable you’re looking for is not called xo-server-logs for the installation done with XenOrchestraInstallerUpdater script. As mentioned above it’s installed beside xo-server as logs-cli.mjs and can be found here (assuming you didn’t change default install location).

$ sudo /opt/xo/xo-server/dist/logs-cli.mjs -h

xo-server-logs --help, -h
…

Help shows command examples as xo-server-logs, but you need to use above executable instead.

You can also easily make xo-server-logs command to work if you wish by running:

sudo ln -s /opt/xo/xo-server/dist/logs-cli.mjs /usr/local/bin/xo-server-logs

But i wouldn’t recommend it if this is needed only once.

@isener just run /opt/xo/xo-server/dist/recover-account-cli.mjs admin@admin.net

@isener said in Forgot password for the webgui:

and when I ping, I get:
ping: xo.my-company.net: Name or service not known

what is wrong?

There is no DNS record for xo.my-company.net or you can’t resolve it from wherever you’re trying now.

xo.my-company.net -> which ip address should this be:
of the xcp-neg server or the server where the xen-orchestar is installed?

from where to run this command:
xo-cli --register http://xo.my-company.net/api/admin@admin.net
the xcp-neg server or the server where the xen-orchestar is installed?

Answer to both would be where XO is installed.

@isener said in Forgot password for the webgui:

I read somewhere that yiu have to use this command in CLI
xo-server-recover-account youremail@here.com

but how to install CLI?

This does not mean you need xo-cli installed. CLI refers to just active shell to your XOA VM, via console or ssh. Just run the command in the shell. If you have XO from sources, there's no such command alias and you need to run the script directly from where your XO is installed, like <installdir>/packages/xo-server/dist/recover-account-cli.mjs

@julien-f haven't seen OOM's after this so looks good, thank you.

I'm running daily installation from sources on multiple different OS's. All have the same specs: 2vCPU/4GB RAM. This has worked flawlessly for a long time. Recently (starting from 4th/5th Nov) i've started to see OOM errors almost daily during yarn build which then cause it to fail with following error:

Using polyfills: No polyfills were added, since the `useBuiltIns` option was not set.
[01:23:25] Finished 'copyAssets' after 36 s
[01:24:33] Finished 'buildScripts' after 1.73 min
[01:24:33] Finished 'build' after 1.73 min
✖ 1
error Command failed with exit code 1.

It isn't consistent, sometimes it's debian that fails, sometimes ubuntu, sometimes centos/almalinux and so on. Something has definitely changed in the build procedure that eats more RAM than it used to.

I’m fine with increasing the RAM if needed. Just wanted to point this out if there’s something out of the ordinary with latest changes.

Settings -> audit. Assuming you have it enabled. If not, nowhere afaik.

Increasing VM disk size from XCP-ng center/XO only makes the block device larger, partition and filesystem (what you see in df output) won’t resize automatically, you need to do it manually inside the VM.

There’s usually little to no reasons to expose any mgmt systems to internet in actual production environments. Especially if it’s strictly for internal mgmt purposes. XO is no exception. Not because the system would be unsecure, but you simply want to make any attack surface as small as possible. It’s just a best a practice.

Okay, nodejs version is up to date then, so XO update will probably succeed as well without much of a hickup. Sure it’s safer if you can create a installation from scratch. XO gui has config export/import feature which you can use to migrate to new installation.

@JanP so you actually didn't update anything, probably just re-ran the installation on top of old codebase. See from sources installation instructions in: https://xen-orchestra.com/docs/installation.html#from-the-sources. Take note that it's perfectly possible that you also need to upgrade your nodejs version to latest LTS.

That'd be the first thing to solve as your installation is very old. It's therefore pointless to debug any issues until you get that XO to latest version as issue you're seeing could've very well be fixed long time ago.

So the answer is no, that is like couple years old. I assume it’s from sources installation then.

Start off by upgrading it to latest version. Instructed also here: https://xen-orchestra.com/docs/community.html

XOA or XO from sources? Is it up to date?

I’m still confused what is asked here and how it’s supposed to work NFS ISO repository works exactly as described, all hosts in the pool should be able to access it once configured (once), no matter how many hosts there are. For separate pools it needs to be added individually.

There are terms like remote and SR mixed here which have nothing to do with each other which is a bit confusing. Remote is a thing purely in Xen Orchestra and SR is something you configure to XCP-ng/Xenserver hosts via XO or other means.

I can reproduce same error with a fresh from sources installation when trying to add server.

Yup, installed nodejs version is beyond LTS version, which could be the cause. It is probably installed manually outside of the script as well since it installs 16.x if missing/too old but doesn’t do anything if version is above.

@vbits looks like you used XenOrchestraInstallerUpdater so i can just reply here.

If you used default user in the scripts config, you can put this timeout override config to /root/.config/xo-server directory and restart xo-server service. If you used other user than root, then same thing but /root -> /users/homedirectory

Sounds like a client side error if it happens with two different remotes on different systems, which probably explains why there’s nothing in server side logs.

Which OS is XO running? Could this be related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949394

Could you try mv on smb share without XO involved to verify it’s not related? Sure it should report other than success if such renaming fails.