It's just we are first focusing on a completely "known" environment (XOA), but I think at some point we'll be able to provide manual setup for people who want to do it from the sources

So proxies are a XOA paid only feature (even without support), and its not possible to manually build, or understand the magic that is going on within the proxy VM ; at least thats something else less to play with and break!

Looks like Plan B then!

@julien-f do we have a "manual" procedure anywhere?

I guess registering it, in Redis I presume, would be easy enough, but what about the proxy VM itself?

Thanks.

However, you should be able to use the sources to register a proxy yourself, but we'll document that later (it's still in dev and code is moving fast).

Anyway, we'll expose that in the UI, thanks for the feedback

The patch is finally here

Sorry for the delay

How to test?

1. Select the latest channel on your XO appliance
2. Upgrade to Xen Orchestra 5.43.2
3. Go to the Proxies page and either Deploy a proxy or upgrade the appliance of your existing ones

What's here?

• Full Backup
• Disaster Recovery

Known limitations/issues

Scheduled for Step 2 at the end of the month.

• Network configuration for the proxy appliance
• Delta Backup
• Continuous Replication
• Detailed logs, they are currently empty
• Restoring backups
  Work-around: create a normal remote (not linked to the proxy) connected to the same storage and import via the XO appliance

Thank you for your feedbacks

Yes the DHCP server give an IP to the proxy

No problem for me to create and configure a proxy but when I start a backup I have this error :

backupNg.runJob
{
  "id": "fad774b1-79ac-485d-9e7d-f3f9de02f486",
  "schedule": "0c9fffd2-8a42-4d87-8098-217dbd2feabc"
}
{
  "code": -32601,
  "data": "backup.run",
  "message": "method not found: backup.run"
} 

proxy.deploy
{
  "sr": "fed313ad-68ac-8ce8-0ced-25f861c3c17f"
}
{
  "message": "operation timed out",
  "name": "TimeoutError",
  "stack": "TimeoutError: operation timed out
    at Promise.call (/usr/local/lib/node_modules/xo-server/node_modules/promise-toolbox/timeout.js:13:16)
    at Proxy.deployProxy (/usr/local/lib/node_modules/xo-server/src/xo-mixins/proxies.js:195:19)
    at <anonymous>"
}

With XO built from source, I received the following error --

proxy.deploy
{
  "sr": "fed313ad-68ac-8ce8-0ced-25f861c3c17f"
}
{
  "message": "app.getResourceCatalog is not a function",
  "name": "TypeError",
  "stack": "TypeError: app.getResourceCatalog is not a function
    at Proxy.apply (/opt/xen-orchestra/packages/xo-server/src/xo-mixins/proxies.js:143:19)
    at Proxy.<anonymous> (/opt/xen-orchestra/node_modules/golike-defer/src/index.js:57:17)
    at Object.deployProxy (/opt/xen-orchestra/node_modules/lodash/_createBind.js:23:15)
    at Object.call (/opt/xen-orchestra/packages/xo-server/src/api/proxy.js:100:15)
    at Api.callApiMethod (/opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.js:292:33)
    at <anonymous>"
}

On selecting a SR, the user should be able to select the associated network and to choose its configuration.

Indeed, in your case you need to give the VM an IP address.

To make this possible, we'll improve our solution to let users be able to select the VM's network and to choose the network configuration.

Sounds good. I'll give it another go then!

To make this possible, we'll improve our solution to let users be able to select the VM's network and to choose the network configuration.

Thank you for your response.

Apparently, the VM is unable to get an IP address. Have you any network configuration which can conflicts with the start of a new VM?

The xcp-ng server is on a public IP but all my VMs are on a private network through NIC1. I would never expect to start a VM and have networking auto configured. I would have to give it an IP address.