Live migration between local storage without a cluster

[virtRoo]

Hi all,

Is it possible to do live migration from one standalone Proxmox host with local storage to another one without joining both to a cluster if the destination host has the same or higher minor version?

I know this is possible on generic CentOS 7 with qemu-kvm-ev, but it seems Proxmox still requires a cluster to achieve this?

Thanks.

 

[mira]

At the moment there's no such feature available. Although there is one patch series still waiting for approval here (https://pve.proxmox.com/pipermail/pve-devel/2019-January/035463.html).

 

[virtRoo]

Just being curious, is there any update with this feature?

 

[mira]

No, no update yet.

 

[virtRoo]

No, no update yet.

Thanks mira. It'd be great if this can be implemented as requiring a cluster setup would be an overkill if one simply wants to live migrate VMs between standalone hosts with local storage, or from one cluster to another cluster.

 

[tom]

Thanks mira. It'd be great if this can be implemented as requiring a cluster setup would be an overkill if one simply wants to live migrate VMs between standalone hosts with local storage, or from one cluster to another cluster.

We are working on this already, as mentioned above.

 

[spirit]

Hi, I was the original author. I didn't have time to update patches for proxmox6

@tom (does the proxmox dev team is working on it currently ?)

 

[mira]

As far as I know nobody is currently actively working on it, but it's still on the TODO list. I'll try to take a look again once I get a chance. Perhaps there's not much to change to get it up and running again. And if I remember correctly there were still some things to discuss.
From looking through the mailing list, it seems v7 is the latest version?

 

[fabian]

it's on my TODO list, but I ordered API tokens first since I want to leverage them to make cross-/inter-cluster access easy to revoke. I see two more building blocks:

- an encrypted tunnel via the API to forward local unix sockets (avoid SSH keys, not strictly necessary for PoC/experimental feature)
- definition of remote clusters/nodes in a config file, so that we can give permissions on them, reference them as targets in API calls, ... (also not strictly necessary for PoC/experimental feature)

that would need to land first to allow proper integration. I haven't decided yet whether I'll rebase your patch first, and then work on the "proper" version as non-experimental feature, or just concentrate on the latter.

 

[spirit]

it's on my TODO list, but I ordered API tokens first since I want to leverage them to make cross-/inter-cluster access easy to revoke. I see two more building blocks:

- an encrypted tunnel via the API to forward local unix sockets (avoid SSH keys, not strictly necessary for PoC/experimental feature)
- definition of remote clusters/nodes in a config file, so that we can give permissions on them, reference them as targets in API calls, ... (also not strictly necessary for PoC/experimental feature)

that would need to land first to allow proper integration. I haven't decided yet whether I'll rebase your patch first, and then work on the "proper" version as non-experimental feature, or just concentrate on the latter.

That's sound great (I'm dreaming of a multi-cluster gui

Also, the drive mirror is still not encrypted if I remember. I think it's possible to do it directly with qemu through tls. (not sure about ssh tunnel performance, as it's limited to 1core)

 

[fabian]

That's sound great (I'm dreaming of a multi-cluster gui

Also, the drive mirror is still not encrypted if I remember. I think it's possible to do it directly with qemu through tls. (not sure about ssh tunnel performance, as it's limited to 1core)

@mira is looking at the drive-mirror already.

 

[SagnikS]

Just stumbled upon this thread when I was looking for something similar to virsh migrate for Proxmox. Is there any update on this by any chance?

 

[andy77]

Would also be very interested on that feature. Any updats on that?

 

[fabian]

did some initial ground work last year and a now severely outdated proof of concept for the migration part - but it's high on my TODO list again for the next months!

 

[bro_escoba]

Hi,
did you had time to have a deeper look on this feature?
It would be a mandatory feature for a current planning of a deployment.

 

[fabian]

I sent another version earlier this year, there are still some kinks to iron out..

 

[Lapointemar]

@fabian @tom @mira Any update on that one guy very interesting feature for us.

 

[fabian]

it's still on the roadmap and being worked on. 5th iteration of the patch series - I hope number 6 or 7 will be the final one