[SOLVED] ZFS (replication) Migration VM startet neu

[Skyfay]

Hey zusammen

Ich habe eine kleine Frage bezüglich ZFS und der Migration zwischen mehreren Hosts.

In meinem Setup habe ich zwei Server welche beide einen ZFS Pool haben wo die VM's drauf sind. Ich nutze Replication um die Disks auf jeweils beiden Hosts aktuell zu halten. Nun habe ich gestern einmal Migrationen getestet und mir ist aufgefallen, dass nach der Migration die VM immer neu gestartet wurde.
Soweit ich mich erinnern konnte, ist das sowohl als die VM's noch auf dem NFS Share liefen als auch mit LVM-thin nicht passiert, da konnte ich eine Live Migration ohne Probleme druchführen.

Meine Frage ist nun ob das ein Fehler ist oder ob das eine Limitierung von ZFS ist?

Ich freue mich auf eure Antworten.

 

[Falk R.]

Sind das VMs oder LXC?

 

[Skyfay]

Sind VM‘s bei LXC weiss ich, dass diese nicht Online ohne herunterfahren migriert werden können.

 

[Falk R.]

Was steht denn im Log beim migrieren?

 

[Skyfay]

2023-11-23 14:21:45 starting migration of VM 226 to node 'sky08' (10.70.10.8)
2023-11-23 14:21:45 found local, replicated disk 'local-zfs:vm-226-disk-0' (attached)
2023-11-23 14:21:45 scsi0: start tracking writes using block-dirty-bitmap 'repl_scsi0'
2023-11-23 14:21:45 replicating disk images
2023-11-23 14:21:45 start replication job
2023-11-23 14:21:45 guest => VM 226, running => 752165
2023-11-23 14:21:45 volumes => local-zfs:vm-226-disk-0
2023-11-23 14:21:46 freeze guest filesystem
2023-11-23 14:21:46 create snapshot '__replicate_226-0_1700745705__' on local-zfs:vm-226-disk-0
2023-11-23 14:21:46 thaw guest filesystem
2023-11-23 14:21:46 using secure transmission, rate limit: none
2023-11-23 14:21:46 incremental sync 'local-zfs:vm-226-disk-0' (__replicate_226-0_1700744401__ => __replicate_226-0_1700745705__)
2023-11-23 14:21:47 send from @__replicate_226-0_1700744401__ to rpool/data/vm-226-disk-0@__replicate_226-0_1700745705__ estimated size is 6.65M
2023-11-23 14:21:47 total estimated size is 6.65M
2023-11-23 14:21:47 successfully imported 'local-zfs:vm-226-disk-0'
2023-11-23 14:21:47 delete previous replication snapshot '__replicate_226-0_1700744401__' on local-zfs:vm-226-disk-0
2023-11-23 14:21:48 (remote_finalize_local_job) delete stale replication snapshot '__replicate_226-0_1700744401__' on local-zfs:vm-226-disk-0
2023-11-23 14:21:48 end replication job
2023-11-23 14:21:48 starting VM 226 on remote node 'sky08'
2023-11-23 14:21:49 volume 'local-zfs:vm-226-disk-0' is 'local-zfs:vm-226-disk-0' on the target
2023-11-23 14:21:49 start remote tunnel
2023-11-23 14:21:49 ssh tunnel ver 1
2023-11-23 14:21:49 starting storage migration
2023-11-23 14:21:49 scsi0: start migration to nbd:unix:/run/qemu-server/226_nbd.migrate:exportname=drive-scsi0
drive mirror re-using dirty bitmap 'repl_scsi0'
drive mirror is starting for drive-scsi0
drive-scsi0: transferred 0.0 B of 11.2 MiB (0.00%) in 0s
drive-scsi0: transferred 11.2 MiB of 11.2 MiB (100.00%) in 1s, ready
all 'mirror' jobs are ready
2023-11-23 14:21:50 starting online/live migration on unix:/run/qemu-server/226.migrate
2023-11-23 14:21:50 set migration capabilities
2023-11-23 14:21:50 migration downtime limit: 100 ms
2023-11-23 14:21:50 migration cachesize: 256.0 MiB
2023-11-23 14:21:50 set migration parameters
2023-11-23 14:21:50 start migrate command to unix:/run/qemu-server/226.migrate
2023-11-23 14:21:51 migration active, transferred 619.4 MiB of 2.0 GiB VM-state, 1.2 GiB/s
2023-11-23 14:21:52 migration active, transferred 1.2 GiB of 2.0 GiB VM-state, 1.5 GiB/s
2023-11-23 14:21:53 average migration speed: 688.3 MiB/s - downtime 142 ms
2023-11-23 14:21:53 migration status: completed
all 'mirror' jobs are ready
drive-scsi0: Completing block job_id...
drive-scsi0: Completed successfully.
drive-scsi0: mirror-job finished
2023-11-23 14:21:54 # /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=sky08' root@10.70.10.8 pvesr set-state 226 \''{"local/sky07":{"duration":2.277653,"last_sync":1700745705,"last_try":1700745705,"fail_count":0,"last_node":"sky07","storeid_list":["local-zfs"],"last_iteration":1700745705}}'\'
2023-11-23 14:21:55 stopping NBD storage migration server on target.
2023-11-23 14:21:58 migration finished successfully (duration 00:00:13)
TASK OK

Und dann halt noch den Start

migration listens on unix:/run/qemu-server/226.migrate
storage migration listens on nbd:unix:/run/qemu-server/226_nbd.migrate:exportname=drive-scsi0 volume:local-zfs:vm-226-disk-0,iothread=1,size=15G
re-using replicated volume: scsi0 - local-zfs:vm-226-disk-0
TASK OK

 

[Falk R.]

Ich sehe da nix vom Boot. Die Livemigration ist laut Log sauber durch.

 

[Falk R.]

Siehst du im Log der VM etwas?

 

[fabian]

dass die VM am zielnode gestartet wird ist ganz normal - dieser neue VM prozess uebernimmt dann im zuge der migration vom alten prozess am quellnode.. prozesse (und nix anderes ist eine VM im endeffekt) koennen ja nicht von einem system aufs andere teleportiert werden

 

[Falk R.]

dass die VM am zielnode gestartet wird ist ganz normal - dieser neue VM prozess uebernimmt dann im zuge der migration vom alten prozess am quellnode.. prozesse (und nix anderes ist eine VM im endeffekt) koennen ja nicht von einem system aufs andere teleportiert werden

Das ist ja normal bei allen Hypervisoren.

@Skyfay was sagt denn das OS der VM?

 

[Skyfay]

dass die VM am zielnode gestartet wird ist ganz normal - dieser neue VM prozess uebernimmt dann im zuge der migration vom alten prozess am quellnode.. prozesse (und nix anderes ist eine VM im endeffekt) koennen ja nicht von einem system aufs andere teleportiert werden

Ach, also die VM lauft auf Node 1, startet dann auf Node 2 und wird dann übergeben und schlussendlich wird Node 1 wieder heruntergefahren?
Weil also ich das ganze mit LVM und NFS damals gemacht habe, war die VM halt noch so am laufen wie auf Node 1 und ich war angemeldet etc.

@Skyfay was sagt denn das OS der VM?

Ich sehe da nichts spezielles, worauf müsste ich denn achten?

 

[fabian]

Weil also ich das ganze mit LVM und NFS damals gemacht habe, war die VM halt noch so am laufen wie auf Node 1 und ich war angemeldet etc.

das sollte unabhaengig vom storage der VM so sein bei einer live migration.. aber wie kommst du denn darauf dass die VM runtergefahren wird?

der ablauf ist so:
- VM wird pausiert auf node 2 gestartet
- disks werden gespiegelt bis sie den gleichen inhalt auf beiden nodes haben (bei lokalem storage, sonst kann dieser schritt uebersprungen werden)
- VM state (memory und co) wird migriert (waehrenddessen laeuft die VM noch auf node 1)
- state ist synchronisiert, VM auf node 1 wird pausiert
- disk spiegelung wird finalisiert
- VM auf node 2 wird fertig gestartet (nicht mehr pausiert)
- pausierte VM auf node 1 wird gestoppt
- lokale volumes auf node 1 werden geloescht

 

[Skyfay]

aber wie kommst du denn darauf dass die VM runtergefahren wird?

Also ich habe die Konsole nebenbei offen und sehe dann halt dass die VM neu startet bzw. startet. Jetzt hab ich es nochmal zwei mal gemacht und natürlich funktioniert es nun wie erwartet haha
Ich werde das mal beobachten.

 

[ubu]

Sind VM‘s bei LXC weiss ich, dass diese nicht Online ohne herunterfahren migriert werden können.

Leider nein, lxcs werden beim migrieren neu gestartet

 

[Skyfay]

Leider nein, lxcs werden beim migrieren neu gestartet

Ja, das hatte ich doch geschrieben es geht hier um VM's

Ich habe nun den Prozess mit einer anderen VM durchgespielt. Lustigerweise das erste mal wenn man eine Migration macht startet er neu und danach funktionieren die Migrationen mit dieser VM jeweils problemlos.
Ich werde gleich einmal die Videos schicken einmal wie es funktioniert und einmal wie es eben meiner Meinung nach nicht funktioniert.

 

[Skyfay]

Hier das Video einmal mit dem Problem und einmal wie es erfolgreich funktioniert

 

[sb-jw]

Hast du noch eine VM die du altmodisch installiert hast? Womöglich hängt das mit Cloud-Init zusammen, dass da erst mal was auf dem anderen Node deployed werden muss, was ggf. vorher nicht da war.

Funktioniert es denn jetzt mit allen VMs out of the Box? Wenn ja, könntest du ja ggf. mal Debian oder sowas probieren mit Cloud-Init und schauen ob es da auch das erste mal so auftritt.

 

[Skyfay]

Hast du noch eine VM die du altmodisch installiert hast?

Wie meinst du das? Also ich hatte alle VM's erstellt damals über den NFS-Share auf mein Synology Nas. Die habe ich jetzt einfach alle "wiederhergestellt" auf den lokalen ZFS Speicher.

 

[sb-jw]

IS

Wie meinst du das?

ISO runterladen, einbinden, Installation durchführen, ISO auswerfen fertige VM haben. Du hast ja hier Cloud-Init genutzt, das sind ja fertige OS Images die einfach nur mit Variablen gefüttert werden.

 

[Skyfay]

IS

ISO runterladen, einbinden, Installation durchführen, ISO auswerfen fertige VM haben. Du hast ja hier Cloud-Init genutzt, das sind ja fertige OS Images die einfach nur mit Variablen gefüttert werden.

Ähm nein, eigentlich nicht. Das war ein normales Ubuntu Server Image welches ich genutzt hatte. Ich habe die alle selber von 0 auf installiert. Habe noch nie etwas mit Cloud-Init gemacht...

 

[sb-jw]

Das sieht für mich eindeutig nach einem Cloud-Init Image aus. Kannst du mal die VM Config hier posten?