@myles3

Hello Myles3. This post is over 20 days old. The issue was since been resolved by support. I dont remember the exact solution off the top of my head with out looking it up.

Just updated to latest commit - 8e2d9. Trying to create new VM in xov6 and a few issues to start.

New vm settings

• Ubuntu 24.04 template
• 4 cpu cores
• 6 gb of ram
• Ubuntu iso mounted
• No option to adjust topology for cpu cores.

VM was created with 1 cpu core no iso disk mounted

@olivierlambert thank for that. Just to be clear the vm was not runing but shut down if that makes a difference.

@ph7 Both firewalls are Unifi Enterprise fortress gateways. - https://techspecs.ui.com/unifi/cloud-gateways/efg?subcategory=all-cloud-gateways

Both sites are setup with Site Magic VPN. So should be full 1.1gbps if accurate.

@nikade Can you elaborate on that more for us? Do you create a new pool with existing host? if so how? or do you pull a host make new pool from that host and migrate the rest over?

@nikade
Doing the copy vm with compression moved at double the speed shown in above screenshots. And finish in half the time. Since it was a copy job it left a copy of the vm on both locations. However starting the copied vm from its original location showed no issues. I then deleted the vm no longer needed in other location.

So question why did vm migration take so long vs vm copy. both instances the vm was powered off.

That is much faster throughput wise. Time wise will seems about the same or longer.

@Pilow

Correct? this would be moving the VM back to its original location.

Still going... And i got to move it back. It is only a test windows server... but

@DustinB

Switches between host on both side are 10gb switchs and nics. only 1gb connection is ISP on both locations. While I didnt expect it to be using the full 1gb i would have thought it would be higher then what it is. Maybe VPN overhead.

As stated this task is not something I would be doing on the regular. So i can live with those speeds. If anyone else has any other ideas to look into or other confirmation please let me know.

@DustinB

Think pictures are in correct order starting with sending host at top and receiving host bottom.

Normal vm operations i have no complaints. Just wanted to make sure there was no artificial limitations imposed by XOA or XO Proxy with going across pools or anything.

@DustinB Updated post with more details. I would assume it would transfer faster. Both locations running Synology with 8 sata ssd's 10gb nics on all connections with internet being the limit of 1gb + vpn.

I just kicked off a vm migration from one pool to another pool over vpn (1gb dedicated Verizon fiber). XO proxy is on the receiving end of this migration. The vm was shutdown when the process started. The migration is still in progress..

I am only getting about 200ish mbps is this expected depending on storage type such... This is probably something I wont need to do often but in the event I do should I go about this a different way?

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.