Migration issue - storage 'zfs1-vps1' is not available on node

[yarii]

In cluster I've got two hosts.
- vps1
- vps2

Each host got it local storage.
- VPS1 got zfspool named zfs1-vps1
- VPS2 got zfspool named zfs1-vps2

On host VPS1 I click "Migrate" on some turned off VM/CT and click OK.

There is always an error:
Task viewer: CT 31337 - Migrate

2020-10-24 13:09:35 ERROR: migration aborted (duration 00:00:00): storage 'zfs1-vps1' is not available on node 'vps2'
TASK ERROR: migration aborted

khmmm... this is local storage and it is only available on localhost

This is reproduceable for each host and diffrent vm/ct.

Why the migration creator doesn't asks for destination storage?

 

[mailinglists]

Try something like: qm migrate 31337 vps2 --targetstorage zfs1-vps2 --online --with-local-disks

 

[yarii]

Why I cannot do this by UI? Is it intentional or the code for frontend was not developed?

 

[yarii]

This is not suitable for containers and pct command.
How to do migration with one click instead of clicking backup&waiting&restore... ?

 

[mailinglists]

Why I cannot do this by UI? Is it intentional or the code for frontend was not developed?

It also has GUI. Depends on the version of PM you use.

 

[yarii]

I use the newest Proxmox. I cannot migrate between nodes when the nodes has local-storages.

 

[ghe]

I use the newest Proxmox. I cannot migrate between nodes when the nodes has local-storages.

based on my experience having hostnames in the storage names is a bad idea

actually your error message

storage 'zfs1-vps1' is not available on node 'vps2'

kind of gives it away: names of source and target storage must be identical.
IIRC even migrating from dir to lvm storage worked as long as both had the same name.

at least when working with gui, API or the pct command

 

[yarii]

> based on my experience having hostnames in the storage names is a bad idea

Why? It's not quite bad...

In moniotoring software - If You got many storages there are distinguishable without aliases...

> kind of gives it away: names of source and target storage must be identical.

There should be an window with target source like in Live Migration.

If You got the same names ZFS pools like 'tank' in all machines and some stops working suddenly and You want to move the disks to another machine You've got conflict names. Your suggestion is complicating fast recovery solutions).

 

[ghe]

I completly agree. GUI and PCT should allow to choose a target storage - but they don't.
so while your naming convention totally makes sense (in fact we used a very similar one) it prohibits you from migrating containers directly.

an awkward workaround would be an additional storage on all nodes (e.g. transfer). you would then have to move the containers disk to that storage, then migrate to the new host and finaly move the disk to the designated storage.
this would not only complicate things - you'd also have to reserve disk space for migration.

very frustrating.

 

[yarii]

Now I do migration by zfs send+ssh and copying config file... but that's smells like temporary solution ;-)

 

[mailinglists]

pve-zsync does that for you and it synces only differences.
I use it when moving my VMs from cluster to cluster.
Sync, stop, sync again, start on new node. config files are in /var/lib/pve-zsznc/..
It takes just 3 minutes of downtime, no matter how big the VM is.

 

[yarii]

its still workaround.... Users need to do one click and forget about that thing.

 

[mailinglists]

Using pve-zsync is not a workaround. It is a standard CLI tool. BUt I get what you mean. I suggest you open a feature request and sponsor it.

 

[yarii]

I opened FR at bug tracker allready after few commants here.

 

[templar]

I opened FR at bug tracker allready after few commants here.

Could you please give a link to FR?

 

[yarii]

https://bugzilla.proxmox.com/show_bug.cgi?id=3148
for --with-local-disks