Just updated to lastest commit https://github.com/vatesfr/xen-orchestra/commit/4bd5b38aeb9d063e9666e3a174944cbbfcb92721
It's fixed now. Working wonderfully. Thanks!
Just updated to lastest commit https://github.com/vatesfr/xen-orchestra/commit/4bd5b38aeb9d063e9666e3a174944cbbfcb92721
It's fixed now. Working wonderfully. Thanks!
@florent said in Continuous Replication health check fails:
@bullerwins nice catch, the fix is trivial with such a detailled error : https://github.com/vatesfr/xen-orchestra/pull/6830
nice! as soon as it's merges I'll update it and check. I'm so happy if this report helped you guys in any way!
@julien-f said in XOA Proxy Error when updating:
@bullerwins XO Proxy Appliance deployment is not supported in XO built from sources.
my bad, it used to work a few months back I believe
@olivierlambert said in XOA Proxy Error when updating:
I missed that in the original message, indeed
FYI @bullerwins there's no such thing as XOA built from sources, you have either:
- XOA is Xen Orchestra virtual Appliance, that's the VM we distribute with pro support and QA/stable channel, updater and such
- XO from the sources is from Github, without pro support but community support, no QA no stable version, no udpater and such
Thanks, I got confused with the naming, I'm using the second option.
As a workaround I used a VPN to manage the remote XCP-ng host, thanks!
@julien-f Thank you so much, I restarted the XOA built from source ubuntu VM and now it works! (how could I not thought of this before #1 rule in IT, turn off and on again).
Thanks a lot for the support.
@Soarin Hi! Would you mind sharing what config did you use for openvpn?
Did you install openvpn in the xcp-ng host? in a vm?
Just updated to lastest commit https://github.com/vatesfr/xen-orchestra/commit/4bd5b38aeb9d063e9666e3a174944cbbfcb92721
It's fixed now. Working wonderfully. Thanks!
@florent said in Continuous Replication health check fails:
@bullerwins nice catch, the fix is trivial with such a detailled error : https://github.com/vatesfr/xen-orchestra/pull/6830
nice! as soon as it's merges I'll update it and check. I'm so happy if this report helped you guys in any way!
@florent said in Continuous Replication health check fails:
@bullerwins hi, can you export the full JOSN log (the button with the downard arrow in the title of the modal ) ?
Sure!
I copied it to pastebin, I can't upload .json's I believe
Hi!
I've been testing both the normal and delta backups, and the DR and Continuous Replication backups with the health checks.
The "normal" backups work fine, it creates a backup and with the health check it boots a copy of the VM and waits for the management tools to load and then destroys it. Works wonders:
But when using the Continuous Replication method, it works fine as long as I don't check the "health check". It actually works "fine", it creates the backup vm, but it doesn't boot it, i can boot it though manually after and it boots fine. Is this normal behavior?
I get the error: Error: task has already ended
Full error log:
{
"data": {
"mode": "delta",
"reportWhen": "failure"
},
"id": "1683735233267",
"jobId": "0ae3a8f1-b21c-4302-a4f4-a175b3766380",
"jobName": "ubuntuBackup",
"message": "backup",
"scheduleId": "fde39c31-a81a-4534-8265-3d63264cd629",
"start": 1683735233267,
"status": "failure",
"infos": [
{
"data": {
"vms": [
"89cc6c0e-4a19-eaf7-edd2-c3189094e66e"
]
},
"message": "vms"
}
],
"tasks": [
{
"data": {
"type": "VM",
"id": "89cc6c0e-4a19-eaf7-edd2-c3189094e66e",
"name_label": "Ubuntu Focal Fossa 20.04 ori"
},
"id": "1683735235212",
"message": "backup VM",
"start": 1683735235212,
"status": "failure",
"tasks": [
{
"id": "1683735235906",
"message": "snapshot",
"start": 1683735235906,
"status": "success",
"end": 1683735237813,
"result": "3504e7ab-240e-5d4b-d09b-97b59a4ae6a8"
},
{
"data": {
"id": "340350a1-1198-edb3-b477-caaad85c02e3",
"isFull": true,
"name_label": "truenas",
"type": "SR"
},
"id": "1683735237814",
"message": "export",
"start": 1683735237814,
"status": "success",
"tasks": [
{
"id": "1683735237848",
"message": "transfer",
"start": 1683735237848,
"status": "success",
"end": 1683735442805,
"result": {
"size": 5181273600
}
}
],
"end": 1683735442889
}
],
"end": 1683735442907,
"result": {
"log": {
"result": {
"log": {
"message": "health check",
"parentId": "aw473bidagq",
"event": "start",
"taskId": "wzq5it9o9ip",
"timestamp": 1683735442901
},
"message": "task has already ended",
"name": "Error",
"stack": "Error: task has already ended\n at Task.logAfterEnd (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:7:17)\n at Task.onLog (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:66:37)\n at #log (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:146:16)\n at new Task (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:82:14)\n at Task.run (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:40:12)\n at DeltaReplicationWriter.healthCheck (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/writers/_MixinReplicationWriter.js:26:19)\n at /opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:136:32\n at /opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:110:24\n at Zone.run (/opt/xo/xo-builds/xen-orchestra-202305091555/node_modules/node-zone/index.js:80:23)\n at Task.run (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:108:23)"
},
"status": "failure",
"event": "end",
"taskId": "aw473bidagq",
"timestamp": 1683735442901
},
"message": "task has already ended",
"name": "Error",
"stack": "Error: task has already ended\n at Task.logAfterEnd (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:7:17)\n at #log (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:146:16)\n at #end (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:141:14)\n at Task.failure (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:90:14)\n at /opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:119:14\n at Zone.run (/opt/xo/xo-builds/xen-orchestra-202305091555/node_modules/node-zone/index.js:80:23)\n at Task.run (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:108:23)\n at DeltaReplicationWriter.healthCheck (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/Task.js:136:19)\n at /opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/_VmBackup.js:458:46\n at callWriter (/opt/xo/xo-builds/xen-orchestra-202305091555/@xen-orchestra/backups/_VmBackup.js:148:15)"
}
}
],
"end": 1683735442908
}
XO build from source today.
@julien-f said in XOA Proxy Error when updating:
@bullerwins XO Proxy Appliance deployment is not supported in XO built from sources.
my bad, it used to work a few months back I believe
@olivierlambert said in XOA Proxy Error when updating:
I missed that in the original message, indeed
FYI @bullerwins there's no such thing as XOA built from sources, you have either:
- XOA is Xen Orchestra virtual Appliance, that's the VM we distribute with pro support and QA/stable channel, updater and such
- XO from the sources is from Github, without pro support but community support, no QA no stable version, no udpater and such
Thanks, I got confused with the naming, I'm using the second option.
As a workaround I used a VPN to manage the remote XCP-ng host, thanks!
Hi!
I just installed the XOA Proxy following the guide from https://xen-orchestra.com/blog/xo-proxy-a-concrete-guide/ but I get an error when trying to upgrade the proxy
The whole error log is:
proxy.upgradeAppliance
{
"id": "3e2ad3d7-f4d1-4eb1-bea0-a6129f12325c",
"ignoreRunningJobs": true
}
{
"message": "this._app.getCurrentChannel is not a function",
"name": "TypeError",
"stack": "TypeError: this._app.getCurrentChannel is not a function
at Proxy._getChannel (file:///opt/xo/xo-builds/xen-orchestra-202305091555/packages/xo-server/src/xo-mixins/proxies.mjs:92:41)
at Proxy.updateProxyAppliance (file:///opt/xo/xo-builds/xen-orchestra-202305091555/packages/xo-server/src/xo-mixins/proxies.mjs:236:79)
at Proxy.upgradeProxyAppliance (file:///opt/xo/xo-builds/xen-orchestra-202305091555/packages/xo-server/src/xo-mixins/proxies.mjs:223:18)
at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202305091555/packages/xo-server/src/xo-mixins/api.mjs:417:20)"
}
This is with XOA built from sources, build commit https://github.com/vatesfr/xen-orchestra/commit/90ce1c4d1ed8d97c024098e26d1fb8ecfd78cb25
I just saw in @lawrencesystems that editing filters was a thing. And after 10min of searching the UI I couln't find it. A quick google search got me to this thread. I didn't even saw the user icon. Maybe adding a text besides like "Profile" would be an option.
Sorry for waking up an old thread.
This would be a more of a theoretical question:
Provided that I already have a VPN tunnel set up between the networks, and I'm going to keep it as I use it for other stuff.
Is there any benefit of using the XO-proxy vs a VPN tunnel installed in the XOA vm?
The way I see it is:
Pro XO-proxy:
-Easier to set up
-No need to update/mantain a vpn client in the host OS and remote network as it updates with XOA and the proxy can be updated with a click.
-Might have advantages down the road if more development is done to the proxy and I'm already using it and no need to migrate from the vpn tunnel method.
-Basically all-in-one solution as I don't need to worry about 3rd party stuff. If I migrate I don't have to worry/remember the vpn stuff to be able to connect.
Con XO-proxy:
-That I have to open another port in the router if I already have a VPN tunnel.
I'm just wondering if it's worth to keep another port open in the router.
@julien-f Thank you so much, I restarted the XOA built from source ubuntu VM and now it works! (how could I not thought of this before #1 rule in IT, turn off and on again).
Thanks a lot for the support.
@julien-f what is the command to restart the proxy? so I can try to do it in the build from sources XOA