Hey Team XPC,

I've got a VM running on an XPC-NG 8.1 host that I think was probably migrated to there from a different vm host (kvm maybe?) several years ago.

The VM is running Zentyal 6.2 which is based on Ubuntu 18.04 and I'm trying to update it to Zentyal 7, which I think also updates the base OS to 20.04.

The upgrade is failing with a message that grub-install /dev/vda failed as it's missing from the device.map. I ran grub-mkdevicemap thinking that would help but then realised that the device is /dev/xvda not /dev/vda. This is why I think the system might have originated with a different hypervisor. To back that up, if I check fstab I see a note to say that "# / was on /dev/vda1 during installation"

So, at some point during the upgrade, grub is being run and told to install it's self to /dev/vda but that doesn't exist any more, problem is that I'm struggling a bit to work out where the /dev/vda is coming from so that I can go fix it. Does anyone have any idea where I might start looking?

I'm struggling to find the warm migration option (looking in advanced) is it on the features that's part of Starter/Enterprise/Premium? I have to admit that this XO is only on the Free account.

@olivierlambert Ok, thanks. I'll look up warm migration and go from there.

@olivierlambert said in Migration woes - SR_BACKEND_FAILURE_78:

logs on source and destination hosts

Are we talking, looking through /var/log or something that is in the XO interface somewhere? Going home, hosts, hostname, logs shows "Nothing so far" for both hosts.

@Danp said in Migration woes - SR_BACKEND_FAILURE_78:

consider some alternative methods to achieve your migration goal

@olivierlambert said in Migration woes - SR_BACKEND_FAILURE_78:

Warm migration is probably the easiest one

Migrate whilst the VM is running? I was trying a migrate whilst shutdown as I assumed that would be easier.

Trying one more time.

Sad times...

Failed again, rhis probably needs a different post as it's a totally different error but if anyone spots this and has any ideas I'd appreciate the pointers;

vm.migrate
{
  "vm": "bb7c8076-728d-4a09-38f1-b227c3d16c2e",
  "mapVdisSrs": {
    "0c793c82-7768-4490-9c42-48b2abd8c819": "baf6a596-d7bd-c9fe-1a16-e1296938194a",
    "582c36f0-a599-4546-9011-a545674dc55e": "ee1d59e1-3036-3764-a152-0b99812b81e7"
  },
  "mapVifsNetworks": {
    "a8ce03de-1675-f19a-a94b-1b50822bd3ff": "d121db64-65ab-ce28-ea15-4e80fd60be5d"
  },
  "migrationNetwork": "aa838565-8ec5-c814-4b17-c8c9d715d54a",
  "sr": "ee1d59e1-3036-3764-a152-0b99812b81e7",
  "targetHost": "b9ede076-9a6c-42f4-b08b-50d84952f8fc"
}
{
  "code": 21,
  "data": {
    "objectId": "bb7c8076-728d-4a09-38f1-b227c3d16c2e",
    "code": "INTERNAL_ERROR"
  },
  "message": "operation failed",
  "name": "XoError",
  "stack": "XoError: operation failed
    at operationFailed (/usr/local/lib/node_modules/xo-server/node_modules/xo-common/src/api-errors.js:21:32)
    at file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:482:15
    at runMicrotasks (<anonymous>)
    at runNextTicks (internal/process/task_queues.js:60:5)
    at processImmediate (internal/timers.js:435:9)
    at process.topLevelDomainCallback (domain.js:147:15)
    at process.callbackTrampoline (internal/async_hooks.js:132:14)
    at Object.migrate (file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:469:3)
    at Api.callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:304:20)"
}

@olivierlambert it's now 22 hours in with an estimated 13 hours to go... Fingers crossed.

Stand by...

I realised that the failure happened within seconds of me starting the migration so did some more digging.

It might be because the previous failed migrations left the partially migrated disks on the SR of the destination and I had run out of disk space as a result... I've cleared the failed disks and started again.

Why do you always notice these things just after you post to a forum...

Hi All,

I'm in the process of migrating some VMs from one server to another. After a couple of initial hicups I have moved 3 of the 4 VMs that I need leaving one large (circa 2tb) one to move.

I was initially having problems because the migration was taking more than 24 hours, so have added "pending_task_timeout = 172800" to a file in /etc/xapi.conf.d and restarted the toolstack.

I am now getting a SR_BACKEND_FAILURE_78 error. Google hasn't helped much (other than a post on the LTS forums from a couple of years ago that I tried to help answer!) but I wondered if anyone could give me some more details on what that specific failure means. Full log is below.

Thanks in advance for any assistance.

vm.migrate
{
  "vm": "bb7c8076-728d-4a09-38f1-b227c3d16c2e",
  "mapVdisSrs": {
    "0c793c82-7768-4490-9c42-48b2abd8c819": "baf6a596-d7bd-c9fe-1a16-e1296938194a",
    "582c36f0-a599-4546-9011-a545674dc55e": "ee1d59e1-3036-3764-a152-0b99812b81e7"
  },
  "mapVifsNetworks": {
    "a8ce03de-1675-f19a-a94b-1b50822bd3ff": "d121db64-65ab-ce28-ea15-4e80fd60be5d"
  },
  "migrationNetwork": "aa838565-8ec5-c814-4b17-c8c9d715d54a",
  "sr": "ee1d59e1-3036-3764-a152-0b99812b81e7",
  "targetHost": "b9ede076-9a6c-42f4-b08b-50d84952f8fc"
}
{
  "code": 21,
  "data": {
    "objectId": "bb7c8076-728d-4a09-38f1-b227c3d16c2e",
    "code": "SR_BACKEND_FAILURE_78"
  },
  "message": "operation failed",
  "name": "XoError",
  "stack": "XoError: operation failed
    at operationFailed (/usr/local/lib/node_modules/xo-server/node_modules/xo-common/src/api-errors.js:21:32)
    at file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:482:15
    at Object.migrate (file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:469:3)
    at Api.callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:304:20)"
}

+1 for FreePBX for sure

would a unifi sdn controller be a sensible option?

I spotted a couple of (probably) mistakes on the new docs. @olivierlambert are you happy for people to just update or would you prefer a list?

I have literally spent most of the day reading through the wiki today, will make my way through the new docs as well. Always good to have more information available.

Love the twit network, I don't normally listen to FLOSS weekly but will go grab this one.