@bogdantomasciuc check https://github.com/ronivay/xenorchestrainstallerupdater
it manages XO Proxies

and ping @acebmxer in the forums who has developped an equivalent

annnnnnd forget about it.

FS was locked in read-only mode, due to a switch reboot and this XO PROXY on an NFS shared SR...

Hello,

Don't know if this is XOA update related. We went from 6.3.3 to 6.7.1 on this infrastructure

proxy.upgradeAppliance
{
  "id": "c567225f-140c-4084-9e3e-f2ccadd7a11f"
}
{
  "code": -32000,
  "data": {
    "stack": "Error: ENOENT: no such file or directory, mkdir '/tmp/xoa-updater'
    at JsonRpcWebSocketClient.<anonymous> (file:///usr/local/lib/node_modules/@xen-orchestra/proxy/app/mixins/appliance.mjs:34:22)
    at JsonRpcWebSocketClient.emit (node:events:519:28)
    at JsonRpcWebSocketClient.emit (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@xen-orchestra/log/configure.js:52:17)
    at Peer.apply (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/jsonrpc-websocket-client/src/index.js:45:12)
    at /usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/json-rpc-peer/src/index.js:14:46
    at new Promise (<anonymous>)
    at Peer._handle (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/json-rpc-peer/src/index.js:14:12)
    at Peer._callee$ (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/json-rpc-peer/src/index.js:103:12)
    at Peer.<anonymous> (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:52:18)
    at Generator.<anonymous> (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@babel/runtime/helpers/regenerator.js:52:51)
    at Generator.next (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@babel/runtime/helpers/regeneratorDefine.js:11:21)
    at asyncGeneratorStep (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:17)
    at _next (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@babel/runtime/helpers/asyncToGenerator.js:17:9)
    at /usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@babel/runtime/helpers/asyncToGenerator.js:22:7
    at new Promise (<anonymous>)
    at Peer.<anonymous> (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/@babel/runtime/helpers/asyncToGenerator.js:14:12)
    at Peer.exec (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/json-rpc-peer/dist/index.js:182:20)
    at Peer.write (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/json-rpc-peer/src/index.js:206:10)
    at JsonRpcWebSocketClient.<anonymous> (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/jsonrpc-websocket-client/src/index.js:57:12)
    at JsonRpcWebSocketClient.emit (node:events:519:28)"
  },
  "message": "ENOENT: no such file or directory, mkdir '/tmp/xoa-updater'"
}

any idea why we can't upgrade this proxy ?

@Tristis-Oris could you not temporarly change the CR VM Mac address on the VIF ?
problem would be solved ?

@acebmxer the two hosts are Masters, probably each in a pool.

@nasheayahu

If I do the reboot, will XCP-ng save the State and Restore or Shutdown the VMs? I was hoping it would save the State and Restore like you can with KVM.

All VMs with AUTO START enabled will start. even if you have some manually shutdown. the host do not care of previous running type, when rebooting and going online, it will start VMs qith autostart enabled (and pool enabled)

@BrantleyHobbs

facepalm situation ! thanks for the feedback

@john.c yeah i'm assuming the 40K is probably VMs, so better density of physical servers
anyway, big players...

@olivierlambert just for fun of thought.
How could Vates stack handle 40K servers farm ?

I suppose TESCO have multiple in house datacenters, and not 40K servers in one place but anyway...
Can this tech handle 40K servers in one XOA with attached sites by XO Proxies ?

way above recommend limits isnt it ?
don't remember the max number of servers per pool

@olivierlambert but we want it to be XCP on Vates stack !

@DustinB said:

the choice appears to be incompatible with both Veeam and Zerto

thought the same XD
40K servers would be a good user story

@manilx yup, same here
we evacuate & roll patch manually because RPU is inconsistent in achieving a full pool update nowadays

maximum hosts in pools are 3, so it is still easy to process manually
thoses with 5-6+ hosts must be more painful

@marcoi perhaps a restart toolstack would correct the phantom task ?
but at the end of patching of the master a restart toolstack should have happened already, automatically...

@Bastien-Nollet Sorry, I had to revert back to 6.3.3, and didnt save the logs...
but as far as I remember, it was not an UI issue, even in the logs it didnt put any transfer informations

@pierrebrunet i'll report back as soon as we test 6.5.1 on this same client infrastructure

@Milenko if this is a definitive migration pathway for you, you can force start the replica VM, no problem, you can even delete the replica snapshot.
Just disable the job at source, it will create a new replica VM otherwise

if it is just a test boot of the replica, fast clone it, and start the fast clone (beware of double ip addressing while doing so... source VM should be halted, or replica clone should be started without network)

@acebmxer had a combo error on some VMs "fell back to full" and "not referenced by any backup" but no tranfer size either.

can't screenshot it anymore, I did a rollback to XOA 6.3 for the time being, snapshoted just before the upgrade

@acebmxer but you have SIZE and SPEED

same error but I do not even have these infos.

did a full VM restoration on an "N/D" backup point, was successful

so it seems backup is backuping buuuuut not reporting correct transfer size

halp

some VMs do take more than 30 seconds, and do not have the error

still no transfer size

and still no apparent size

is the XO backup working ?!

Hi,

Today we updated from XOA 6.3.3 to 6.5
XCP is full up to date.

Since then, the backups are successful but do not seem to transfer any data ?
Comparison between yesterday and today :

Each job goes like that :

restore point size is N/D !

XOA seems to be working

any idea @florent @bastien-nollet ?

@tsukraw I think the bottleneck is indeed the tapdisk and smapiv1.

We have full 10Gb WDM between nominal and DR site, and get the same transfer speeds as you on CR.