Yes, it's technically possible, as long as the underlying hardware is compatible. For example, you can't put a server using AMD processors into a pool with Intel processors.

The server being moved into the existing pool will lose its local storage and all VMs stored there, so you will need to migrate those VMs to the main pool before the server is merged. Afterwards, you can move them back if desired.

@julien-f Technically, it is possible with post processing as I mentioned above. Here's an example using jq and awk --

 xo-cli --list-objects type=VM-snapshot | jq '.[]."$snapshot_of"' | sort | uniq -c | awk -F " " '{print "{\"uuid\":" $2 ",\"count\":" $1"}"}'| jq ' select( .count > 1)'

Output looks like this --

{
  "uuid": "07604606-e937-5147-2dac-c1b4280df234",
  "count": 2
}
{
  "uuid": "0f11c701-c5e5-b09b-4c5f-00cf38153783",
  "count": 2
}
{
  "uuid": "83139da5-48d5-33f6-79f9-79ea91a7163c",
  "count": 2
}
{
  "uuid": "fb4703e4-bfd6-47b8-3fd1-f1f52f9ed234",
  "count": 2
}
{
  "uuid": "ff8b29e3-4445-5b22-e475-450270f2a7f3",
  "count": 2
}

Note: I am not proficient with these linux utilities so there may be better ways to accomplish this.

There was a recent change that resulted in the launched module being renamed. You need to redo your service so that it loads ./dist/cli.mjs instead of ./bin/xo-server

You're running out of memory. Allocate more memory to the VM. I believe the current build requirement is 3GB.

You need a space between the URL and the user name.

@stormi Updated and rebooted. I'll report back if I encounter any issues.

Updated Dell R620 / XCP-ng 8.1. Rebooting all VMs now, but they appear to be coming up just fine.

@hvilches said in XCP-ng Center 20.03.00 released:

is-a-template ( RW): true

Looks like this is the culprit...

@flipsidecreations There's a new Netdata plugin, which appears to only be available in XOA Premium edition. It doesn't appear that you will be able to enable the new Advanced Live Telemetry using the versions you are currently running.

@olivierlambert The "quick deploy" via web worked correctly this time

@jcdick1 Could it be the same problem described here?

Maybe a routing issue, such that the XOA VM can't "see" the remote xcp-ng server?

Check to Troubleshooting documentation, which explained where the logs are located in xcp-ng.

@olivierlambert Does that change need to be manually reverted or is does it automatically revert following the full backup?

I'm not positive, but it looks like you have enabled the Centos repo, which would definitely cause the issue you are seeing. Have you read the docs on additional packages?

P.S. 7.6 is like ancient. I hope you plan on upgrading to 8.2 soon.

Have you enabled additional repositories on your xcp-ng server? What does the output of yum repolist look like when you run it on the server?

@julien-f NFS

Unsure if this is related, but I've found some errors in the logs that I don't believe occurred prior to the most recent updates --

Dec 28 00:19:10 xo-server[257773]: 2021-12-28T06:19:10.418Z xo:main WARN WebSocket send: {
Dec 28 00:19:10 xo-server[257773]:   error: Error: Cannot call write after a stream was destroyed
Dec 28 00:19:10 xo-server[257773]:       at new NodeError (node:internal/errors:371:5)
Dec 28 00:19:10 xo-server[257773]:       at errorBuffer (node:internal/streams/writable:517:14)
Dec 28 00:19:10 xo-server[257773]:       at afterWrite (node:internal/streams/writable:501:5)
Dec 28 00:19:10 xo-server[257773]:       at onwrite (node:internal/streams/writable:477:7)
Dec 28 00:19:10 xo-server[257773]:       at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:91:12)
Dec 28 00:19:10 xo-server[257773]:       at WriteWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
Dec 28 00:19:10 xo-server[257773]:     code: 'ERR_STREAM_DESTROYED'
Dec 28 00:19:10 xo-server[257773]:   }
Dec 28 00:19:10 xo-server[257773]: }

Also this --

Dec 28 00:00:13 xo-server[360334]: 2021-12-28T06:00:13.194Z xo:xapi:vm WARN HANDLE_INVALID(VDI, OpaqueRef:83be31a3-81d7-4be3-9714-0ad1fa034d20) {
Dec 28 00:00:13 xo-server[360334]:   error: XapiError: HANDLE_INVALID(VDI, OpaqueRef:83be31a3-81d7-4be3-9714-0ad1fa034d20)
Dec 28 00:00:13 xo-server[360334]:       at Function.wrap (/opt/xen-orchestra/packages/xen-api/dist/_XapiError.js:26:12)
Dec 28 00:00:13 xo-server[360334]:       at /opt/xen-orchestra/packages/xen-api/dist/transports/json-rpc.js:58:30
Dec 28 00:00:13 xo-server[360334]:       at runMicrotasks (<anonymous>)
Dec 28 00:00:13 xo-server[360334]:       at processTicksAndRejections (node:internal/process/task_queues:96:5) {
Dec 28 00:00:13 xo-server[360334]:     code: 'HANDLE_INVALID',
Dec 28 00:00:13 xo-server[360334]:     params: [ 'VDI', 'OpaqueRef:83be31a3-81d7-4be3-9714-0ad1fa034d20' ],
Dec 28 00:00:13 xo-server[360334]:     call: { method: 'VDI.get_record', params: [Array] },
Dec 28 00:00:13 xo-server[360334]:     url: undefined,
Dec 28 00:00:13 xo-server[360334]:     task: undefined
Dec 28 00:00:13 xo-server[360334]:   }
Dec 28 00:00:13 xo-server[360334]: }
Dec 28 00:00:13 xo-server[360334]: 2021-12-28T06:00:13.393Z xo:xapi:vm WARN HANDLE_INVALID(VDI, OpaqueRef:83be31a3-81d7-4be3-9714-0ad1fa034d20) {
Dec 28 00:00:13 xo-server[360334]:   error: XapiError: HANDLE_INVALID(VDI, OpaqueRef:83be31a3-81d7-4be3-9714-0ad1fa034d20)
Dec 28 00:00:13 xo-server[360334]:       at Function.wrap (/opt/xen-orchestra/packages/xen-api/dist/_XapiError.js:26:12)
Dec 28 00:00:13 xo-server[360334]:       at /opt/xen-orchestra/packages/xen-api/dist/transports/json-rpc.js:58:30
Dec 28 00:00:13 xo-server[360334]:       at runMicrotasks (<anonymous>)
Dec 28 00:00:13 xo-server[360334]:       at processTicksAndRejections (node:internal/process/task_queues:96:5) {
Dec 28 00:00:13 xo-server[360334]:     code: 'HANDLE_INVALID',
Dec 28 00:00:13 xo-server[360334]:     params: [ 'VDI', 'OpaqueRef:83be31a3-81d7-4be3-9714-0ad1fa034d20' ],
Dec 28 00:00:13 xo-server[360334]:     call: { method: 'VDI.get_record', params: [Array] },
Dec 28 00:00:13 xo-server[360334]:     url: undefined,
Dec 28 00:00:13 xo-server[360334]:     task: undefined
Dec 28 00:00:13 xo-server[360334]:   }
Dec 28 00:00:13 xo-server[360334]: }

@julien-f It's the same delta backup job that I've been using forever --

It uses smart mode to backup all running VMs. Scheduled to run daily at midnight, backup retention is set to 12.

Currently on commit 5bc4436, I'm still experiencing repeated full backups but this isn't occurring on all VMs.

@julien-f Any suggestions on how to diagnose the cause?