Migration websock remains open and nothing happening

1

I am trying to migrate an instance from 192.168.1.150 to 192.168.1.160 , despite lxc operation list showing there is an operation pending
b9a490f7-e7df-4695-983b-9ff4ed0b01b3 | WEBSOCKET | Migrating container | RUNNING | NO | 2020/05/31 16:00 UTC
I send the create instance request, and it goes through fine, but the web socket remains open on .150 but and 160 does not do anything, is there something else i am suppose to do?

{
    "name": "alpine-01",
    "architecture": "x86_64",
    "profiles": [
        "default"
    ],
    "ephemeral": false,
    "config": {
        "image.architecture": "amd64",
        "image.description": "Alpine 3.11 amd64 (20200531_13:00)",
        "image.os": "Alpine",
        "image.release": "3.11",
        "image.serial": "20200531_13:00",
        "image.type": "squashfs",
        "limits.cpu": "1",
        "limits.memory": "1GB",
        "volatile.base_image": "0b900b1bd25de4f0c27a1b5d733f210bb30ba9f21c0f0910b8e9887f6265be89",
        "volatile.eth0.hwaddr": "00:16:3e:7e:a3:d3",
        "volatile.idmap.base": "0",
        "volatile.idmap.current": "[{\"Isuid\":true,\"Isgid\":false,\"Hostid\":1000000,\"Nsid\":0,\"Maprange\":1000000000},{\"Isuid\":false,\"Isgid\":true,\"Hostid\":1000000,\"Nsid\":0,\"Maprange\":1000000000}]",
        "volatile.idmap.next": "[{\"Isuid\":true,\"Isgid\":false,\"Hostid\":1000000,\"Nsid\":0,\"Maprange\":1000000000},{\"Isuid\":false,\"Isgid\":true,\"Hostid\":1000000,\"Nsid\":0,\"Maprange\":1000000000}]",
        "volatile.last_state.idmap": "[{\"Isuid\":true,\"Isgid\":false,\"Hostid\":1000000,\"Nsid\":0,\"Maprange\":1000000000},{\"Isuid\":false,\"Isgid\":true,\"Hostid\":1000000,\"Nsid\":0,\"Maprange\":1000000000}]",
        "volatile.last_state.power": "STOPPED"
    },
    "source": {
        "type": "migration",
        "mode": "pull",
        "operation": "https:\/\/192.168.1.150:8443\/operations\/586680bb-c2e5-4034-a64f-a970ecbb2d65",
        "certificate": "-----BEGIN CERTIFICATE----- foo -----END CERTIFICATE-----\n",
        "secrets": {
            "control": "16cb92de0741ff361f649511df9b97f171cdbde02f120ef99a87377363a08794",
            "fs": "38f2231abb55d66a224ed2fcdaa7cfb6b6afcf127ac60f2bdb96e731ab948d3b"
        }
    },
    "devices": {
        "root": {
            "path": "\/",
            "pool": "default",
            "size": "1GB",
            "type": "disk"
        }
    }
2

Try using lxc copy --mode=relay as a way to avoid potential network issues, see if that helps.

3

But i want to do this via the API

4

Ok, and you sent the needed POST to both source and target?

If that’s an option for you, easiest is to use the CLI and pass --debug to it to see what it’s sending to the source and target, then replicate that in your own logic.

1 Like
5

I think i found the problem, the operation url, is incorrect, it is missing 1.0
"operation": "https:\/\/192.168.1.150:8443\/operations\/586680bb-c2e5-4034-a64f-a970ecbb2d65",

7

The --debug is brilliant, thank you!!

8

@stgraber. can you explain the three copy modes?
There seems to be no explanation.

Thank you

9

pull is default, target server is provided with URL to operation on the source, push instead has the receiving server give you websockets that are passed to the source to push to, relay uses push on the source and pull on the target with the command line client acting as intermediary, connecting to both source and target and relaying data.

1 Like
10

Thank you @stgraber.

Can I habitually use relay mode to avoid common problems?
Or, there are 3 modes. Is there a separate case for each of the 3 modes?

11

Relay is fine to use, the main issue with it is if you’re doing some remote admin over VPN or other as the entire traffic will be routed through the CLI.

If you have fast access and bandwidth to both source and target from wherever you’re running the CLI tool, then it’s all fine.

12

Thank you @stgraber