Confirm commit 1a7b5 backups completed successfully.

Updated AMD Ryzen pool at home and update two Intel Dell r660 and r640 pools at work. No issues to report back.

@stormi

Thanks for the reply back. Update when sucessfull. Windows Server 2025 iso now properly installs.

At work I was not able to install default certs for UEFI due to one failing to download. Run these updates and I was able to successfully install the certs to the host.

i have applied updates to my 2 amd home lab hosts. Ryzen 7700x and 7950x amd x670e mobo's. No issues to report. Windows vm migrated between hosts no isssues. No issues with windows vm booting with uefi enabled prior to update.

@WorkAccount1000

Reach out to who's script you are using for deploying XO from sources.

This script - https://github.com/ronivay/XenOrchestraInstallerUpdater there is an option in the config file to enable XOv6. There are concerns with not being fully ready to its disabled by default. I currently have not any issues related to that.

@MathieuRA

Again thank you so much for you time trying to assist with this. The script OP has responded and updated the script to work correctly now.

Again thank to all Vates staff for all the hard work you do that goes unnoticed.

@dinhngtu Well those directions didnt work as I was unable to locate the setup.exe file in any of the vmware directories. I asked google ai how to force uninstall the vmware tools and started to follow those directions of maunally deleting the services and folder and registry entries. However the vm pysically became unbootable. It would not show the logo of the bios starting up. The vm would appear to be starting up but no console screen would load. I even tried to restore from a backup taken two days ago. That VM started up and of coarse windows wanted todo updates and vm became unbootable again.

I deleted all previous vm and did a fresh migration. This time i did remove the tools prior to the migration. VM is back working.

@Pilow

Did dirty upgrade left all boxes checked and vm is setup to update drivers via windows update....

I have rebooted vm and restarts no issues.

@dinhngtu same mine where two fresh VMs fresh install of server 2025. Older iso works newer iso does not. For me the newer iso the system rebooted 2 maybe 3 times then crashed to a hard power off of the vm.

Again no xen tools installed as os never finished installing on a fresh vm. no OS upgrade.

as @MBNext stated disabling Purge snapshot data when using CBT worked for me.

Restarting tool stack on master host of remote pool cleared the stuck job and backup was able run failed vms.

Support ticket still open fyi.

I have opened a support ticket and tunnel is open - Ticket#7749796

here is a section of the error log. I have rebooted XOA and rebooted the Proxy but yet the job still remains hung. Maybe i didn't reboot them in the correct order? As stated support ticket and tunnel are open.

   {
         "id": "1766901730734",
         "message": "snapshot",
         "start": 1766901730734,
         "status": "success",
         "end": 1766901734483,
         "result": "a995b25e-ab77-a217-fccd-7e8a1d06df57"
       },
       {
         "data": {
           "id": "3022703c-5029-4ac3-bda1-3a76c6634a39",
           "isFull": true,
           "type": "remote"
         },
         "id": "1766901734494",
         "message": "export",
         "start": 1766901734494,
         "status": "interrupted",
         "tasks": [
           {
             "id": "1766901737246",
             "message": "transfer",
             "start": 1766901737246,
             "status": "interrupted"
           }
         ]
       }
     ],
     "infos": [
       {
         "message": "Transfer data using NBD"
       }
     ]
   }
 ],
 "end": 1766901871318,
 "result": {
   "url": "https://10.120.20.119/api/v1",
   "message": "HTTP connection has timed out",
   "name": "Error",
   "stack": "Error: HTTP connection has timed out\n    at ClientRequest.<anonymous> (/usr/local/lib/node_modules/xo-server/node_modules/http-request-plus/index.js:61:25)\n    at ClientRequest.emit (node:events:518:28)\n    at ClientRequest.patchedEmit [as emit] (/usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/log/configure.js:52:17)\n    at TLSSocket.emitRequestTimeout (node:_http_client:849:9)\n    at Object.onceWrapper (node:events:632:28)\n    at TLSSocket.emit (node:events:530:35)\n    at TLSSocket.patchedEmit [as emit] (/usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/log/configure.js:52:17)\n    at TLSSocket.Socket._onTimeout (node:net:595:8)\n    at listOnTimeout (node:internal/timers:581:17)\n    at processTimers (node:internal/timers:519:7)"

schedule.runSequence
{
  "schedules": [
    "3a677031-4eb9-427a-99fc-22afa411b745",
    "cadef7b9-2541-4850-9bfd-871d9602c6bb",
    "599d9321-7081-4840-9617-d31762d4764c",
    "828b5e60-4302-455c-94f1-479a8001f955"
  ]
}
{
  "url": "https://10.120.20.119/api/v1",
  "message": "HTTP connection has timed out",
  "name": "Error",
  "stack": "Error: HTTP connection has timed out
    at ClientRequest.<anonymous> (/usr/local/lib/node_modules/xo-server/node_modules/http-request-plus/index.js:61:25)
    at ClientRequest.emit (node:events:518:28)
    at ClientRequest.patchedEmit [as emit] (/usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/log/configure.js:52:17)
    at TLSSocket.emitRequestTimeout (node:_http_client:849:9)
    at Object.onceWrapper (node:events:632:28)
    at TLSSocket.emit (node:events:530:35)
    at TLSSocket.patchedEmit [as emit] (/usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/log/configure.js:52:17)
    at TLSSocket.Socket._onTimeout (node:net:595:8)
    at listOnTimeout (node:internal/timers:581:17)
    at processTimers (node:internal/timers:519:7)"

backupNg.runJob
{
  "id": "bb0adfc7-93b9-45c9-a90f-7aa327f95a05",
  "schedule": "3a677031-4eb9-427a-99fc-22afa411b745",
  "vms": [
    "4c2fb974-f2d5-b0fb-7385-1683e0275ef2",
    "025f71ff-ecb2-9d0c-7692-f7005d22c659",
    "78aecc3d-4817-a11c-04b4-9d0f49f8736e",
    "9f36a8c5-c988-8546-b0f9-30ac9d0a5015",
    "db89c6f0-3330-7180-b5e4-7f2f36a241e6",
    "e5c656bb-8bb2-461e-a801-402ae150d022"
  ]
}
{
  "code": -32000,
  "data": {
    "jobId": "bb0adfc7-93b9-45c9-a90f-7aa327f95a05",
    "stack": "Error: job is already running
    at file:///usr/local/lib/node_modules/@xen-orchestra/proxy/app/mixins/backups.mjs:96:25
    at file:///usr/local/lib/node_modules/@xen-orchestra/proxy/app/mixins/backups.mjs:114:20
    at processTicksAndRejections (node:internal/process/task_queues:95:5)"
  },

@Mathieu ok. Yeah I already had that enabled. Glad you got it working.

@Mathieu I do use NGINX Proxy Manager and i have no issues accessing XO-CE via the new v6 default or the old v5 with working links.

As @probain has stated there have been quite a few updates pushed to fix most issues. My issues were related to the script i used to install XO-CE. The script creator had to update the script to the recent changes made.

Make sure you are on the latest commit and/or update your script and try again.

@dinhngtu thank must have read that part with my eyes closed or something.

@stormi

In regards to UEFI Secure boot in recent update.

from pool master host.

[19:09 xcp-ng-qhfpcnmb ~]# rpm -q varstored
varstored-1.2.0-3.4.xcpng8.3.x86_64

8.3 with varstored >= 1.2.0-3.4
Secure Boot is ready to use on new VMs without extra configuration. Simply activate Secure Boot on your VMs, and they will be provided with an appropriate set of default Secure Boot variables.

We will keep updating the default Secure Boot variables with future updates from Microsoft. If you don't want this behavior, you can lock in these variables by using the Manually Install the Default UEFI Certificates procedure.

So new vms nothing is needed to be done. But what about existing vms windows or linux? It it was stated I apologize if i missed it.

@MajorP93

I think ronivay is doing something with Xen Orchestra which is why @mathieura suggestions were not working. I tried to follow his changes in the none docker script but it was above my head. Either way glad he was able to resolve your issues as well.

@MathieuRA

Again thank you so much for you time trying to assist with this. The script OP has responded and updated the script to work correctly now.

Again thank to all Vates staff for all the hard work you do that goes unnoticed.

@MathieuRA said in XO5 breaks after defaulting to XO6 (from source):

@acebmxer Can you provide me with the logs from xo-server at its launch?

Here you go. I made the changes you last suggested to me then I did a restart - sudo systemctl restart xo-server

before change-log.txt
after change-log.txt

Let me know if i did that correctly or if you need more information.

@MathieuRA

I appriciate your assistance with this but broke everything.... no /v5 or /v6 responce.

Anyone using this script - https://github.com/ronivay/XenOrchestraInstallerUpdater able to get this working with v6 as default?

[http.mounts]
164 # Uncomment to setup a default version.
165 # Otherwise, XO5 will be the default for stable channel and XO6 for latest and source
166 # '/' = '../xo-web/dist/'
167                                                                                                                                                          
168 '/v5' = '../xo-web/dist/'                                                                                                                                
169 '/' = '../../@xen-orchestra/web/dist/'
170 
171 [http.proxies]
172 # [port] is used to reuse the same port declared in [http.listen.0]
173 '/v5/api' = '[protocol]//localhost:[port]/api'
174 '/v5/api/updater' = 'ws://localhost:9001'
175 '/v5/rest' = 'http://localhost:[port]/rest'