[SOLVED] ZFS migration -vs- replication

S

skydiablo

New Member
Dec 10, 2020
14
2
3
42
Moin,
habe 2 VM-server mit identischer version:

Code: 
# pveversion
pve-manager/6.3-3/eee5f901 (running kernel: 5.4.78-2-pve)

nun habe ich dort jeweils zwei neue SSDs rein gezimmert und dort ein pool auf einem ZFS mirrored verbund definiert:

Code: 
# zpool status
  pool: local-ssd
 state: ONLINE
  scan: none requested
config:

    NAME                        STATE     READ WRITE CKSUM
    local-ssd                   ONLINE       0     0     0
      mirror-0                  ONLINE       0     0     0
        scsi-35002538b0122d550  ONLINE       0     0     0
        scsi-35002538b0122d830  ONLINE       0     0     0


soweit alles schick, anschließend habe ich jeweils auf beiden servern ein neues ZFS storage definiert: local-ssd-pve07 und local-ssd-pve08
ich denke bisher alles kein großes magic, jetzt eine neue VM (vm-112) auf dem VM-server pve08 eingerichtet und die virtuelle festplatte auf dem neu angelegten storage local-ssd-pve08 hinterlegt. Jetzt beginnen die probleme auf meine reise... da ich die VM in einem HA betrieb halten will richte ich anschließend eine replication ein, intervall ist an dieser stelle vorerst egal. die replication läuft auch wie zu erwarten, einzige voraussetzung ist, das immer beide local-storages auf beiden servern als verfügbar eingerichtet sind. starte ich nun aber eine migration, wird jedesmal die komplette virtuelle festplatte rüber kopiert und auch dupliziert, also habe ich am ende vm-112-disk-0 und vm-112-disk-1 auf dem ziel VM-server:

Migration LOG:
Code: 
2021-03-10 10:01:24 use dedicated network address for sending migration traffic (100.64.0.53)
2021-03-10 10:01:24 starting migration of VM 112 to node 'pve07' (100.64.0.53)
2021-03-10 10:01:24 found local disk 'local-ssd-pve07:vm-112-disk-0' (via storage)
2021-03-10 10:01:24 found local, replicated disk 'local-ssd-pve08:vm-112-disk-0' (in current VM config)
2021-03-10 10:01:24 scsi0: start tracking writes using block-dirty-bitmap 'repl_scsi0'
2021-03-10 10:01:24 replicating disk images
2021-03-10 10:01:24 start replication job
2021-03-10 10:01:24 guest => VM 112, running => 45983
2021-03-10 10:01:24 volumes => local-ssd-pve08:vm-112-disk-0
2021-03-10 10:01:26 create snapshot '__replicate_112-0_1615366884__' on local-ssd-pve08:vm-112-disk-0
2021-03-10 10:01:26 using secure transmission, rate limit: none
2021-03-10 10:01:26 incremental sync 'local-ssd-pve08:vm-112-disk-0' (__replicate_112-0_1615366801__ => __replicate_112-0_1615366884__)
2021-03-10 10:01:28 send from @__replicate_112-0_1615366801__ to local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__ estimated size is 84.0M
2021-03-10 10:01:28 total estimated size is 84.0M
2021-03-10 10:01:28 TIME        SENT   SNAPSHOT local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__
2021-03-10 10:01:29 successfully imported 'local-ssd-pve08:vm-112-disk-0'
2021-03-10 10:01:29 delete previous replication snapshot '__replicate_112-0_1615366801__' on local-ssd-pve08:vm-112-disk-0
2021-03-10 10:01:30 (remote_finalize_local_job) delete stale replication snapshot '__replicate_112-0_1615366801__' on local-ssd-pve08:vm-112-disk-0
2021-03-10 10:01:30 end replication job
2021-03-10 10:01:31 copying local disk images
2021-03-10 10:01:33 full send of local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__ estimated size is 9.67G
2021-03-10 10:01:33 send from @__replicate_112-0_1615366884__ to local-ssd/vm-112-disk-0@__migration__ estimated size is 6.60M
2021-03-10 10:01:33 total estimated size is 9.67G
2021-03-10 10:01:33 TIME        SENT   SNAPSHOT local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__
2021-03-10 10:01:33 volume 'local-ssd/vm-112-disk-0' already exists - importing with a different name
2021-03-10 10:01:34 10:01:34    195M   local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__
2021-03-10 10:01:35 10:01:35    441M   local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__
2021-03-10 10:01:36 10:01:36    689M   local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__
...
2021-03-10 10:02:20 10:02:20   9.51G   local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__
2021-03-10 10:02:21 10:02:21   9.71G   local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__
2021-03-10 10:02:21 TIME        SENT   SNAPSHOT local-ssd/vm-112-disk-0@__migration__
2021-03-10 10:02:22 10:02:22   3.04M   local-ssd/vm-112-disk-0@__migration__
2021-03-10 10:02:23 successfully imported 'local-ssd-pve07:vm-112-disk-1'
2021-03-10 10:02:23 volume 'local-ssd-pve07:vm-112-disk-0' is 'local-ssd-pve07:vm-112-disk-1' on the target
2021-03-10 10:02:23 starting VM 112 on remote node 'pve07'
2021-03-10 10:02:26 start remote tunnel
2021-03-10 10:02:28 ssh tunnel ver 1
2021-03-10 10:02:28 starting storage migration
2021-03-10 10:02:28 scsi0: start migration to nbd:unix:/run/qemu-server/112_nbd.migrate:exportname=drive-scsi0
drive mirror re-using dirty bitmap 'repl_scsi0'
drive mirror is starting for drive-scsi0
drive-scsi0: transferred: 0 bytes remaining: 45416448 bytes total: 45416448 bytes progression: 0.00 % busy: 1 ready: 0
drive-scsi0: transferred: 45416448 bytes remaining: 0 bytes total: 45416448 bytes progression: 100.00 % busy: 0 ready: 1
all mirroring jobs are ready
2021-03-10 10:02:29 volume 'local-ssd-pve08:vm-112-disk-0' is 'local-ssd-pve08:vm-112-disk-0' on the target
2021-03-10 10:02:29 starting online/live migration on unix:/run/qemu-server/112.migrate
2021-03-10 10:02:29 set migration_caps
2021-03-10 10:02:29 migration speed limit: 8589934592 B/s
2021-03-10 10:02:29 migration downtime limit: 100 ms
2021-03-10 10:02:29 migration cachesize: 4294967296 B
2021-03-10 10:02:29 set migration parameters
2021-03-10 10:02:29 start migrate command to unix:/run/qemu-server/112.migrate
2021-03-10 10:02:30 migration status: active (transferred 91576970, remaining 31236915200), total 34377375744)
2021-03-10 10:02:30 migration xbzrle cachesize: 4294967296 transferred 0 pages 0 cachemiss 0 overflow 0
2021-03-10 10:02:31 migration status: active (transferred 224679688, remaining 29043949568), total 34377375744)
...
2021-03-10 10:02:40 migration xbzrle cachesize: 4294967296 transferred 0 pages 0 cachemiss 0 overflow 0
2021-03-10 10:02:40 migration status: active (transferred 1294900135, remaining 3719168), total 34377375744)
2021-03-10 10:02:40 migration xbzrle cachesize: 4294967296 transferred 0 pages 0 cachemiss 1509 overflow 0
2021-03-10 10:02:40 migration speed: 2730.67 MB/s - downtime 32 ms
2021-03-10 10:02:40 migration status: completed
2021-03-10 10:02:46 ERROR: removing local copy of 'local-ssd-pve07:vm-112-disk-0' failed - zfs error: cannot destroy 'local-ssd/vm-112-disk-0': dataset is busy
drive-scsi0: transferred: 45547520 bytes remaining: 0 bytes total: 45547520 bytes progression: 100.00 % busy: 0 ready: 1
all mirroring jobs are ready
drive-scsi0: Completing block job...
drive-scsi0: Completed successfully.
drive-scsi0 : finished
2021-03-10 10:02:47 # /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve07' root@100.64.0.53 pvesr set-state 112 \''{"local/pve08":{"last_sync":1615366884,"last_iteration":1615366884,"last_node":"pve08","storeid_list":["local-ssd-pve08"],"duration":6.399821,"fail_count":0,"last_try":1615366884}}'\'
2021-03-10 10:02:49 stopping NBD storage migration server on target.
2021-03-10 10:02:55 ERROR: migration finished with problems (duration 00:01:32)
TASK ERROR: migration problems

ergebnis auf den servern schaut dann so aus:

Code: 
root@pve08:/mnt/pve/cephfs/_trash# zfs list
NAME                      USED  AVAIL     REFER  MOUNTPOINT
local-ssd                9.52G  1.67T       96K  /local-ssd
local-ssd/vm-112-disk-0  9.50G  1.67T     9.50G  -

Code: 
root@pve07:~# zfs list
NAME                      USED  AVAIL     REFER  MOUNTPOINT
local-ssd                19.1G  1.66T       96K  /local-ssd
local-ssd/vm-112-disk-0  9.56G  1.66T     9.50G  -
local-ssd/vm-112-disk-1  9.51G  1.66T     9.50G  -

will ich nun vom VM-server pve07 zurück auf den pve08 geht es im aktuellen beispiel gar nicht mehr:

Log:
Code: 
2021-03-10 11:16:50 use dedicated network address for sending migration traffic (100.64.0.54)
2021-03-10 11:16:50 starting migration of VM 112 to node 'pve08' (100.64.0.54)
2021-03-10 11:16:50 found local disk 'local-ssd-pve07:vm-112-disk-0' (via storage)
2021-03-10 11:16:50 found local disk 'local-ssd-pve07:vm-112-disk-1' (via storage)
2021-03-10 11:16:50 found local, replicated disk 'local-ssd-pve08:vm-112-disk-0' (in current VM config)
2021-03-10 11:16:50 found local disk 'local-ssd-pve08:vm-112-disk-1' (via storage)
2021-03-10 11:16:50 scsi0: start tracking writes using block-dirty-bitmap 'repl_scsi0'
2021-03-10 11:16:50 replicating disk images
2021-03-10 11:16:50 start replication job
2021-03-10 11:16:50 guest => VM 112, running => 29652
2021-03-10 11:16:50 volumes => local-ssd-pve08:vm-112-disk-0
2021-03-10 11:16:52 create snapshot '__replicate_112-0_1615371410__' on local-ssd-pve08:vm-112-disk-0
2021-03-10 11:16:52 using secure transmission, rate limit: none
2021-03-10 11:16:52 full sync 'local-ssd-pve08:vm-112-disk-0' (__replicate_112-0_1615371410__)
2021-03-10 11:16:54 full send of local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__ estimated size is 9.67G
2021-03-10 11:16:54 send from @__replicate_112-0_1615366884__ to local-ssd/vm-112-disk-0@__replicate_112-0_1615371410__ estimated size is 54.1M
2021-03-10 11:16:54 total estimated size is 9.72G
2021-03-10 11:16:54 TIME        SENT   SNAPSHOT local-ssd/vm-112-disk-0@__replicate_112-0_1615366884__
2021-03-10 11:16:54 volume 'local-ssd/vm-112-disk-0' already exists
2021-03-10 11:16:54 command 'zfs send -Rpv -- local-ssd/vm-112-disk-0@__replicate_112-0_1615371410__' failed: got signal 13
send/receive failed, cleaning up snapshot(s)..
2021-03-10 11:16:54 delete previous replication snapshot '__replicate_112-0_1615371410__' on local-ssd-pve08:vm-112-disk-0
2021-03-10 11:16:54 end replication job with error: command 'set -o pipefail && pvesm export local-ssd-pve08:vm-112-disk-0 zfs - -with-snapshots 1 -snapshot __replicate_112-0_1615371410__ | /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve08' root@100.64.0.54 -- pvesm import local-ssd-pve08:vm-112-disk-0 zfs - -with-snapshots 1 -allow-rename 0' failed: exit code 255
2021-03-10 11:16:54 ERROR: Failed to sync data - command 'set -o pipefail && pvesm export local-ssd-pve08:vm-112-disk-0 zfs - -with-snapshots 1 -snapshot __replicate_112-0_1615371410__ | /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve08' root@100.64.0.54 -- pvesm import local-ssd-pve08:vm-112-disk-0 zfs - -with-snapshots 1 -allow-rename 0' failed: exit code 255
2021-03-10 11:16:54 aborting phase 1 - cleanup resources
2021-03-10 11:16:54 scsi0: removing block-dirty-bitmap 'repl_scsi0'
2021-03-10 11:16:54 ERROR: migration aborted (duration 00:00:05): Failed to sync data - command 'set -o pipefail && pvesm export local-ssd-pve08:vm-112-disk-0 zfs - -with-snapshots 1 -snapshot __replicate_112-0_1615371410__ | /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve08' root@100.64.0.54 -- pvesm import local-ssd-pve08:vm-112-disk-0 zfs - -with-snapshots 1 -allow-rename 0' failed: exit code 255
TASK ERROR: migration aborted

was ich jetzt nicht gestestet habe ist wenn ich den ganzen VM-server abschalte und quasi ein ausfall simuliere wie sich hier die migration verhält? auch ob die VM an oder aus ist macht kein unterschied (online/offline migration), mach ich grundsätzlich etwas falsch? benennung der pools? benennung der ZFS storages?

über ein feedback würde ich mich freuen... grüße, volker...
 
jetzt habe ich noch einmal alle pools gelöscht via zpool destroy local-ssd und fdisk /dev/sdX und via GUI die storages entfernt. nun habe ich auf beiden servern (pve07 + pve08) jeweils ein neuen pool (zwei SSDs via mirror) erstellt und diesmal für jeden server ein anderen pool namen verwendet (local-ssd-pve07 + local-ssd-pve08) und jeweils ein gleichnamigen storage in der GUI angelegt.
wenn ich jetzt eine replication (pve08 -> pve07) anlegen will beschwert er sich dass ich dass er am server pve07 nicht auf das storage local-ssd-pve08 zugreifen kann.

Code: 
2021-03-11 08:04:01 112-0: start replication job
2021-03-11 08:04:01 112-0: guest => VM 112, running => 0
2021-03-11 08:04:01 112-0: volumes => local-ssd-pve08:vm-112-disk-0
2021-03-11 08:04:03 112-0: (remote_prepare_local_job) storage 'local-ssd-pve08' is not available on node 'pve07'
2021-03-11 08:04:03 112-0: end replication job with error: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve07' root@100.64.0.53 -- pvesr prepare-local-job 112-0 local-ssd-pve08:vm-112-disk-0 --last_sync 0' failed: exit code 255

das ist quasi auch richtig, ändere ich nun in den storage einstellungen dass die zfs-pools von pve08 + pve07 gegenseitig zu sehen sind, dann kann man auch schon in der GUI sehen dass die jeweils anderen storages ein "ein kleines graues fragezeichen" haben. starte ich nun die replication erneut, kommt folgender output im log:

Code: 
2021-03-11 08:42:01 112-0: start replication job
2021-03-11 08:42:01 112-0: guest => VM 112, running => 0
2021-03-11 08:42:01 112-0: volumes => local-ssd-pve08:vm-112-disk-0
2021-03-11 08:42:03 112-0: (remote_prepare_local_job) zfs error: cannot open 'local-ssd-pve08': no such pool
2021-03-11 08:42:03 112-0: (remote_prepare_local_job)
2021-03-11 08:42:03 112-0: (remote_prepare_local_job) zfs error: cannot open 'local-ssd-pve08': no such pool
2021-03-11 08:42:03 112-0: (remote_prepare_local_job)
2021-03-11 08:42:03 112-0: (remote_prepare_local_job) could not activate storage 'local-ssd-pve08', zfs error: cannot open 'local-ssd-pve08': no such pool
2021-03-11 08:42:03 112-0: (remote_prepare_local_job)
2021-03-11 08:42:03 112-0: end replication job with error: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve07' root@100.64.0.53 -- pvesr prepare-local-job 112-0 local-ssd-pve08:vm-112-disk-0 --last_sync 0' failed: exit code 1

ergo, heißen die pools auf beiden servern gleich, geht es nicht (siehe mein ersten post) und benne ich die pools jeweils anders geht es auch nicht. somit noch einmal die frage, was mache ich falsch?
 
Also... nach meinem Verständnis sollten alle Storages idealerweise auf allen Nodes identische Namen haben. Ich habe beispielsweise überall einen "ds0", der technisch durchaus unterschiedlich realisiert sein kann. Das gilt insbesondere auch für Speicher, der jeweils nur lokal existiert, also nicht Shared-Storage ist. Dann kann man VMs von NodeX zu NodeY migrieren und replizieren.

Viele Grüße
 
da gebe ich dir recht, wollte ich auch so machen, ABER:

ich lege auf meinem beiden servern meine zfs-pools an (im aktuellen fall mit unterschiedlichen namen), wenn ich jetzt ein zfs storage anlegen möchte muss ich ja den entsprechenden pool angeben. also gehe ich auf den server (GUI) pve08 mit der IP x.x.x.54 und unter storage lege ich ein zfs storage mit dem namen local-ssd an. nun gehe ich auf den zweiten server (GUI) mit der iP x.x.x.53 und möchte nun erneut ein zfs-storage anlegen mit dem namen local-ssd was mir (natürlich?) verweigert wird da es schon ein storage mit dem namen gäbe... was nun? lege ich den storage falsch an, ist mein verstandnis von zfs-storage falsch? bisher fehlt mir etwas eine genaue aussage wie man das im detail machen soll? denke immer das ich etwas falsch mache?
 
okay, solved! das ding muss wirklich überall gleich heißen! der zfs-pool muss identisch heißen und dann reicht es auch den storage nur 1x an zu legen und auf die vorbereiteten server zu limitieren. läuft nun, manchmal muss einfach nur jemand den denk-anstoß geben! vielen dank dafür! ergo, ich habe das prinzip und die umsetzung falsch verstanden... wieder was gelernt, danke!
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back