Storage migration von nfs nach zfs scheitert

[Rufus Ebonhawk]

Hallo,

wir versuchen storage von einem shared nfs auf ein lokales zfs umzuziehen, was nicht gelingt:

qm move_disk 999 scsi0 pve-images --delete

storage migration failed: mirroring error: VM 999 qmp command 'drive-mirror' failed - Could not open '/dev/zvol/tank/pve-images/vm-999-disk-1': No such file or directory

/dev/vol/tank/pve-manager ist vorhanden, andere VMs liegen dort und laufen.

Was könnte die Ursache sein? Hat jemand eine Idee?

pveversion -v
proxmox-ve: 5.1-42 (running kernel: 4.13.16-2-pve)
pve-manager: 5.1-51 (running version: 5.1-51/96be5354)
pve-kernel-4.13: 5.1-44
pve-kernel-4.13.16-2-pve: 4.13.16-47
pve-kernel-4.13.13-2-pve: 4.13.13-33
corosync: 2.4.2-pve4
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.0-8
libpve-apiclient-perl: 2.0-4
libpve-common-perl: 5.0-30
libpve-guest-common-perl: 2.0-14
libpve-http-server-perl: 2.0-8
libpve-storage-perl: 5.0-18
libqb0: 1.0.1-1
lvm2: 2.02.168-pve6
lxc-pve: 3.0.0-2
lxcfs: 3.0.0-1
novnc-pve: 0.6-4
proxmox-widget-toolkit: 1.0-15
pve-cluster: 5.0-25
pve-container: 2.0-21
pve-docs: 5.1-17
pve-firewall: 3.0-8
pve-firmware: 2.0-4
pve-ha-manager: 2.0-5
pve-i18n: 1.0-4
pve-libspice-server1: 0.12.8-3
pve-qemu-kvm: 2.11.1-5
pve-xtermjs: 1.0-2
qemu-server: 5.0-25
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.7-pve1~bpo9

 

[re-host.eu]

Hallo,

wir versuchen storage von einem shared nfs auf ein lokales zfs umzuziehen, was nicht gelingt:





/dev/vol/tank/pve-manager ist vorhanden, andere VMs liegen dort und laufen.

Was könnte die Ursache sein? Hat jemand eine Idee?

Wenn /dev/vol/tank/pve-manager vorhanden ist, warum willst du die VMs dann nach /dev/zvol/tank/pve-images/... ziehen? Ist /dev/zvol/tank/pve-images/ vorhanden?

 

[Rufus Ebonhawk]

Weil ich mich verschrieben habe

Ich meinte
"/dev/vol/tank/pve-images" ist vorhanden, andere VMs liegen dort und laufen.

Hatte in diversen Posts von "/dev/zvol nicht vorhanden" gelesen, wollte klar machen, das /dev/zvol da ist.

qm move_disk erhält ja die Storage-ID als Parameter, also in unserem Fall "pve-images". Daraus löst dann qm move_disk den Pfad /dev/zvol/tank/pve-images auf. Mit dem Pfad direkt hantieren wir ja nicht.

 

[Rufus Ebonhawk]

zfspool: pve-images
pool tank/pve-images
content images
nodes node1,node2
sparse 1

root@neo:/etc/pve # ls -la /dev/zvol/tank/pve-images/
lrwxrwxrwx 1 root root 14 May 7 11:22 vm-112-disk-1 -> ../../../zd128
lrwxrwxrwx 1 root root 14 May 7 11:22 vm-112-disk-2 -> ../../../zd144
lrwxrwxrwx 1 root root 14 May 7 11:22 vm-112-disk-3 -> ../../../zd160
lrwxrwxrwx 1 root root 13 May 7 11:22 vm-116-disk-1 -> ../../../zd48
lrwxrwxrwx 1 root root 14 May 7 11:22 vm-116-disk-2 -> ../../../zd112
lrwxrwxrwx 1 root root 13 May 7 11:22 vm-210-disk-1 -> ../../../zd80
lrwxrwxrwx 1 root root 13 May 7 11:22 vm-210-disk-2 -> ../../../zd96
lrwxrwxrwx 1 root root 13 May 7 11:22 vm-211-disk-1 -> ../../../zd64

 

[Rufus Ebonhawk]

Wir glauben das ist die Ursache des Problems:

Der Effekt tritt nur auf, wenn ein Replication Task aktiv läuft. Läuft keiner kann Storage in den zpool migriert werden.

Auch neue Storage-Images für VM können nicht erstellt werden, wenn ein Replication Task läuft.

Das wirkt wie ein Bug, oder?

 

[Rufus Ebonhawk]

Versuche auf einen anderen zpool zu migrieren oder ein neues Storage-Image zu erstellen scheitern auch während ein Replication Task läuft.

Migrieren wir auf ein nicht-zfs Storage oder erstellen in einem nicht-zfs Storage ein Storage-Image, funktionierts.

Ist also zfs bezogen, ein Lock der beim Replication Task gesetzt wird?

 

[fabian]

ist ein bekanntest problem (https://bugzilla.proxmox.com/show_bug.cgi?id=1691 : das anlegen von zvols ist async, wenn der node unter starker ZFS last steht wird das nicht richtig abgefangen). ist im git bereits gefixed, und wird in libpve-storage-perl 5.0-21 enthalten sein.