@ieugen Read the blog post that XCP-NG posted today on this very topic, but even if the decided to stick with CentOS 8 Stream for the future base platform, they have selective control over which packages/updates would get released for XCP-NG.

I've already switched my CentOS 8.x installs to CentOS 8 Stream. Fedora is too buggy and too far upstream of RedHat for my personal taste. CentOS 8 Steam is supposed to be positioned between Fedora and RedHat, so they might just hit the sweet spot.

Of course, if XCP-NG switched to Ubuntu LTS releases as the base going forward, I wouldn't cry about that either, so I anticipate this announcement from RedHat won't really affect XCP-NG and we'll look back on this and realize it was not a big deal.

@olivierlambert No problem, to be honest I'd forgotten that the script I was using was not the official script...

@badrAZ said in Orphan VDIs after every backup:

issue

Thanks, I've subscribed to the github issue and will build XO as soon as I see the pull request is applied.

@geoffbland Hi, thanks for the reply... That's what I wound up doing, installing XO from source on a Raspberry PI that I had. I used it to restore my XO image from backup, once I did that I had to restore all of my guests (12 of them total).

I could never figure out how to get my SR out of maintenance mode, so I wound up creating a new SR and restored each backup to the new SR. All back to normal after restoring the backup. Thank god XO backup works so well!

I learned the hard way that I need to move my XO disks to local storage before I enter maintenance mode for my iSCSI SR... Oh well, lesson learned!

@Danp Thank you for the reply, but unfortunately I see no parameter named unpluggedPbds in other config:

xe sr-list

uuid ( RO)                : d9b6d7eb-36cc-dd18-d031-4f470963f747
          name-label ( RW): truenas1_iscsi0
    name-description ( RW): iSCSI SR [192.168.5.2 (iqn.2005-10.org.freenas1.ctl:freenas1-iscsi0; LUN 0: 10000001: 2 TB (FreeNAS))]
                host ( RO): <shared>
                type ( RO): lvmoiscsi
        content-type ( RO): 

xe sr-param-get uuid=d9b6d7eb-36cc-dd18-d031-4f470963f747 param-name=other-config

xo:maintenanceState: {"timestamp":1657297413067}; auto-scan: false

It seems that maintenanceState is set to the time I disabled the SR, but not sure how to proceed.

Any ideas?

Hmmm... I seem to have painted myself into a corner using the new SR maintenance mode...

I run XO as a VM under XCP-NG and used XO to enable maintenance mode on the storage, without thinking in advance that my XO instance would not be able to disable maintenance mode!

I've tried to "xe vm-start name-label=xo" but it fails, presumably because its VDIs have been disconnected by the XO storage maintenance mode.

Going forward, I can prevent this by moving my XO instance VDIs to another SR, before I enable maintenance mode on the SR, but now that I've created a mess, how can I get my XO VM running again to disable maintenance mode on the SR?

Thanks

@olivierlambert Thank you... One follow-up question, I presume if I duplicate the backup jobs I should ensure that they're only enabled from one xo instance at a time, correct?

Hi, I have been running my XO instances as guests under XCP-NG, but I just built a new xo-server running on a Raspberry Pi. Is there a way to export the backup jobs I have created in my original xo instance or do I have to recreate them from scratch on the new xo instance?

Thanks

@indyj ok

@olivierlambert No problem, to be honest I'd forgotten that the script I was using was not the official script...

@olivierlambert From sources yes, but I am using the script/install procedure documented here:

https://github.com/ronivay/XenOrchestraInstallerUpdater

I'll follow-up with @ronivay on his github page, thanks.

Hi, trying to build XO from sources and receiving the following error:

Mar 08 14:24:27 xolab.threeputt.org systemd[1]: Started XO Server.
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]: internal/modules/cjs/loader.js:818
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:   throw err;
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:   ^
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]: Error: Cannot find module 'bluebird'
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]: Require stack:
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]: - /etc/xo/xo-builds/xen-orchestra-202103081423/packages/xo-server/bin/xo-server
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     at Function.Module._resolveFilename (internal/modules/cjs/loader.js:815:15)
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     at Function.Module._load (internal/modules/cjs/loader.js:667:27)
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     at Module.require (internal/modules/cjs/loader.js:887:19)
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     at require (internal/modules/cjs/helpers.js:74:18)
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     at Object.<anonymous> (/etc/xo/xo-builds/xen-orchestra-202103081423/packages/xo-server/bin/xo-server:21:18)
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     at Module._compile (internal/modules/cjs/loader.js:999:30)
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     at Module.load (internal/modules/cjs/loader.js:863:32)
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     at Function.Module._load (internal/modules/cjs/loader.js:708:14)
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12) {
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:   code: 'MODULE_NOT_FOUND',
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:   requireStack: [
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:     '/etc/xo/xo-builds/xen-orchestra-202103081423/packages/xo-server/bin/xo-server'
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]:   ]
Mar 08 14:24:27 xolab.threeputt.org xo-server[4970]: }
Mar 08 14:24:27 xolab.threeputt.org systemd[1]: xo-server.service: Main process exited, code=exited, status=1/FAILURE
Mar 08 14:24:27 xolab.threeputt.org systemd[1]: xo-server.service: Failed with result 'exit-code'.
Mar 08 14:24:27 xolab.threeputt.org systemd[1]: xo-server.service: Service RestartSec=100ms expired, scheduling restart.
Mar 08 14:24:27 xolab.threeputt.org systemd[1]: xo-server.service: Scheduled restart job, restart counter is at 5.
Mar 08 14:24:27 xolab.threeputt.org systemd[1]: Stopped XO Server.
Mar 08 14:24:27 xolab.threeputt.org systemd[1]: xo-server.service: Start request repeated too quickly.
Mar 08 14:24:27 xolab.threeputt.org systemd[1]: xo-server.service: Failed with result 'exit-code'.
Mar 08 14:24:27 xolab.threeputt.org systemd[1]: Failed to start XO Server.

Any suggestions how to fix? Thanks.

@olivierlambert Thanks. Patches came out for XCP-NG 8 today and I powered up my 2nd XCP-NG server to apply pool patches, the load balancer promptly took it down...

Lesson learned, I guess I need to temporary disable my density policy before I power up the 2nd server!