Komisches Verhalten beim Migrieren

[chrigiboy]

Hallo,

Wir haben einen neuen Proxmox Server da die anderen 4 im selben Cluster bald voll sind. Nun wollten wir einige wichtige Server die mehr Leistung brauchen migrieren.

Der erste Server war kein Problem. Die Migration verlief problemlos. Beim zweiten funktionierte ebenfalls alles Problemlos. Beim dritten Server stellen wir erstmals fest, dass die Festplatte während dem Transfer an Ihre Grenzen gelangt. Dies jedoch nicht während dem ganzen Transfer. Die ersten 5% bringen den Server fast zum abstürzen. MySQL auf einer VM ist schon mal komplett abgestürzt! Nach diesem ersten 5% läuft jedoch alles wieder flüssig obwohl der Transfer noch im Gange ist. Wir haben verschiedene Theorien dazu, weshalb dies passieren könnte. Wenn wir das klären könnten weshalb genau diese 5% und was man dagegen machen kann wäre das Toll. Der Sinn der Live Migration ist es ja eben die Server normal laufen zu lassen und gleichzeitig den Server zu verschieben.

Angehängt ist noch ein Screenshot von "iotop" während einer Migration.

 

[sb-jw]

Was für einen Shared Storage nutzt ihr denn?

 

[chrigiboy]

Wir benutzen local-LVM mit LiveMigration. Mittlerweile haben wir auch herausgefunden, dass alle anderen vServer abstürzen resp. EXT4 Fehler aufweisen durch den Kopiervorgang.

wenn man ein System mit einer grossen Festplatte (z.B. 2 TB) von Proxmox A nach Proxmox B Live-migriert, erstellt Proxmox B 'vermutlich' eine Festplatte voller NULLEN. Dabei werden ca. 15 Prozesse bei Proxmox B gestartet. Iotop zeigt bei allen 15 Prozessen eine Auslastung von 99,9 der IO's an. Der Erstellungsprozess arbeitet mit voller Last mit ca. 1500 bis 2000 Mbyte/s
Bei grossen Festplatten local-lvm kommt es dann zu einem Hänger von Proxmox B. Alle darauf befindlichen Server hatten dadurch EXT4 Fehler (ca. 40 Stück)! Die auf Proxmox B befindlichen Server waren dann auch nicht mehr erreichbar. Auch der komplette Proxmox B Server war als Node nicht mehr ersichtlich!
Sobald der eigentliche Kopierprozess startet (1Gbit mit 120 MByte/s), beruhigt sich die Lage nach etwa 5 bis 10% der Kopiervorganges.

Was kann man tun, damit es bei der Live Migration mit local-lvm zu keiner Störung kommt? BWLimit limitiert ja nur das Netzwerk aber nicht den ersten Schritt, beim erstellen der Platte. Vorallem finde ich 15 Prozesse mit einer IO Auslastung von 99,9% übertrieben!

Zwischenzeitlich habe ich noch einen weiteren Thread gefunden der diesem Problem sehr ähnlich kling:
https://forum.proxmox.com/threads/v...torage-kills-i-o-on-destination-server.40208/

 

[fabian]

LVM-thin oder reguläres LVM?

 

[chrigiboy]

Es handelt sich um LVM-thin

 

[fabian]

auf LVM-thin ist das initiale Schreiben leider sehr teuer, bei großen volumes ist das leicht spürbar..

 

[chrigiboy]

Mit "leicht spürbar" meinst du EXT4 Fehler auf allen Server, instabiler Server, nicht erreichbarkeit aller VM's, defekte VM Festplatten uvm?
Das ist nicht nur 'leicht spürbar' sondern ganz extrem schlimm. Dieser Bug muss man unbedingt beheben, es darf doch nicht sein, dass eine Migration zu Festplattenausfällen und Unterbrüche der VMs führt! Was kann man nun tun?

 

[fabian]

Entschuldige, dass war in der Tat missverständlich formuliert. "Leicht" war hier im Sinne von "ohne Aufwand", "einfach" nicht im Sinne von "nicht gravierend" gemeint. Wie genau lauten die EXT4 Fehler? Ich vermute, dass für den Zeitraum der Überlastung keine Writes möglich sind, und sich das aus Sicht der VM wie eine defekte/nicht verfügbare Festplatte äußert..

Das Problem ist dass LVM für jeden allozierten Datenblock/chunk erstmal 0en drüber schreiben muss (das macht LVM selbst, AFAICT gibt es da keine Möglichkeit eine Bremse zu setzen), bevor er dann nochmal mit den echten Daten beschrieben wird. Das lässt sich zwar komplett abdrehen (sh. "Zeroing" in der LVM-Thin Doku), aber dann steht in den Blöcken (teilweise) Müll.

Für große Volumes und häufiger Migration empfiehlt es sich auf jeden Fall, eine Form von Shared Storage zu implementieren - dann muss nur der RAM der VM migriert werden, die Volumes werden einfach von der Quell- zur Ziel-VM weitergegeben.

 

[chrigiboy]

Hallo,
danke für deine Ausführung. Leider kommt zur Zeit ein Shared Storage nicht in Frage, da wir rund 30 GByte/s Durchsatz benötigen und wir bislang kein Shared Storage gefunden haben, welches uns diese Geschwindigkeit bringen kann (2x PCIe3.0 x16 Volllast mit NVME bestückt). Wir haben Ceph angeschaut und haben nicht nur unzureichende Performance, auch die Stabilität ist fragwürdig, wenn mal das ganze Rechenzentrum stromlos ist, die Server unterschiedlich schnell booten und dann CEPH nicht mehr ordnungsgemäss starten kann. So ist bei Ceph kein Server mehr erreichbar, während bei lokalen Festplatten ggf. ein einzelner Server nicht mehr booten kann.
Aber hier soll es nicht um einen Thread zwischen Netzwerk vs Local Storage gehen sondern um die Möglichkeit eine LiveMigration einer lokalen Disk.

Die EXT4 Fehler sind völlig unterschiedlich. Teilweise ist die Harddisk in der VM nur noch READ Only und das System muss neugestartet werden. Dabei bleibt der Server beim Bootvorgang hängen (initramfs), und möchte dann das System scannen. Dabei werden einige defekte Blöcke gefunden. Teilweise muss ca. 50 bis 60 Mal die Fehlerbehebung mit Yes bestätigt werden. Zudem gibt es Schäden am Dateisystem mit korrupten Dateien die nicht mehr gelesen werden können, so musste Postfix und andere Module komplett neu kompiliert werden, da die Dateien beschädigt waren. (Übrigens spielt es keine Rolle ob der Cache ein oder ausgeschaltet ist, die Probleme treten bei allen Systemen mit allen HDD Cacheoptionen auf.)

Übrigens haben wir die Probleme beim VMDK import nicht! Da wird ja auch eine Festplatte angelegt. Dort treten diese Probleme nicht auf. Mir ist aufgefallen, dass beim VMDK nur etwa 5 Prozesse laufen anstatt 15. Wie unterscheidet sich denn die Live-Migration bei der Erstellung der Disk mit dem VMDK import?

 

[fabian]

Könntest du eventuell noch eine VM config posten?

Bei der Live Migration mit lokalen Platten erfolgt der Transfer über NBD, beim lokalen Import "direkt". Zusätzlich gibts noch den Unterschied Offline zu Online/Live, wo sehr unterschiedliche Mechanismen zum Einsatz kommen (sowohl bei der Migration, also auch bei "Move Disk" - Import ist immer mit 'qemu-img convert').

 

[chrigiboy]

Import welcher Funktioniert:
qm importdisk 221 /vmdisk/sr65.vhdx local-lvm


Live-Migration mit Aussetzern (über Netzwerk):
qm migrate 114 server2 --online --with-local-disks

Beispiel Config:
#Product%3A Rootserver (VM) (ID%3A 7255)
acpi: 1
agent: 1
autostart: 1
boot: cdn
bootdisk: scsi1
cores: 3
cpu: kvm64
cpulimit: 12
cpuunits: 1000
ide0: none,media=cdrom
kvm: 1
memory: 20000
name: myserver.tld
net0: e1000=5A:74:EE:C0:BB:E3,bridge=vmbr0
numa: 0
onboot: 1
ostype: other
reboot: 1
scsi1: local-lvm:vm-190-disk-0,cache=unsafe,discard=on,size=1T
scsihw: virtio-scsi-pci
smbios1: uuid=f8472fc4-413b-4e7b-9923-d3f680d9770a
sockets: 4
vcpus: 12
vga: vmware
vmgenid: c564ea2a-5e6b-4c65-af8b-02cdd60f91d7

 

[fabian]

Laufen alle VMs mit cache=unsafe? Wie der Name impliziert, kann es hier bei Problemen am Hypervisor zu Datenverlust kommen (unsafe heißt, dass aus VM-Sicht sync und async gleich behandelt wird - d.h. Software in der VM glaubt ein Write ist rausgeschrieben, tatsächlich ist dem aber nicht so). Die kaputten VM-Volumes sind vermutlich ein Resultat aus kompletter Überlastung durch LVM-Thin Zeroing von 1TB + "unsafe" Cache Modus.

Treten während der Migration am Host irgendwelche Fehlermeldungen im Journal auf? Wie sieht es mit der Auslastung des Thin-Pools aus? Eventuell läuft der Thin-Pool während der Migration auch temporär voll (die 1TB müssen nämlich wegen des Umwegs über NBD bei der Live Migration erstmal voll alloziert werden!), das könnte auch Ursache von korrupten Volumes sein.

 

[chrigiboy]

Hallo,
nein nicht alle laufen unsafe. Wie oben erwähnt spielt es keine Rolle ob da unsafe steht oder nicht. Wir haben bei beiden Einstellungen genau die gleichen Probleme. D.h. VMs auf dem gleichen Zielsystem, egal ob unsafe oder nicht, haben DISK Probleme.
Meinst du mit Auslastung die Belegung oder die Auslastung von iotop? Die Speicherbelegung liegt bei 8 TB von 15 TByte. Wir belegen nie mehr als 70%

Leider weiss ich nicht mehr so genau, wann ich VM 129 migriert habe. Es muss zwischen 00.00 und 03.00 Uhr gewesen sein. Leider werden die Migrate Tasks in Proxmox GUI gelöscht wenn der Task beendet wurde.

Hier der Auszug vom Zielserver:
Jun 28 23:26:44 server2 kernel: [969419.350688] NOHZ: local_softirq_pending 28a
Jun 29 00:45:03 server2 vzdump[35453]: <root@pam> starting task UPID:server2:00008A81:05CE6DA8:5D16986F:vzdump:114:root@pam:
Jun 29 00:45:04 server2 qm[35462]: <root@pam> update VM 114: -lock backup
Jun 29 00:53:58 server2 qm[37402]: <root@pam> starting task UPID:server2:00009222:05CF3EA5:5D169A86:qmstart:129:root@pam:
Jun 29 00:53:59 server2 kernel: [974654.414256] device tap129i0 entered promiscuous mode
Jun 29 00:53:59 server2 kernel: [974654.440189] vmbr0: port 26(tap129i0) entered blocking state
Jun 29 00:53:59 server2 kernel: [974654.440194] vmbr0: port 26(tap129i0) entered disabled state
Jun 29 00:53:59 server2 kernel: [974654.440630] vmbr0: port 26(tap129i0) entered blocking state
Jun 29 00:53:59 server2 kernel: [974654.440635] vmbr0: port 26(tap129i0) entered forwarding state
Jun 29 00:54:00 server2 qm[37402]: <root@pam> end task UPID:server2:00009222:05CF3EA5:5D169A86:qmstart:129:root@pam: OK
Jun 29 02:14:13 server2 pveupdate[45472]: <root@pam> starting task UPID:server2:0000B1B9:05D697A6:5D16AD55:aptupdate::root@pam:
Jun 29 02:55:28 server2 pvedaemon[22014]: <root@pam> starting task UPID:server2:0000C4D8:05DA5E56:5D16B700:qmshutdown:114:root@pam:
Jun 29 02:57:55 server2 pvedaemon[21551]: <root@pam> update VM 219: -scsi1 local-lvm:vm-219-disk-0,discard=on,size=2000G
Jun 29 02:57:55 server2 pvedaemon[21551]: <root@pam> starting task UPID:server2:0000C6D7:05DA97D0:5D16B793:qmconfig:219:root@pam:
Jun 29 02:57:55 server2 pvedaemon[21551]: <root@pam> end task UPID:server2:0000C6D7:05DA97D0:5D16B793:qmconfig:219:root@pam: OK
Jun 29 02:57:59 server2 pvedaemon[50625]: <root@pam> starting task UPID:server2:0000C6EF:05DA994A:5D16B797:qmstop:219:root@pam:
Jun 29 02:58:07 server2 kernel: [982101.686572] fwbr219i0: port 2(tap219i0) entered disabled state
Jun 29 02:58:07 server2 kernel: [982101.745530] fwbr219i0: port 1(fwln219i0) entered disabled state
Jun 29 02:58:07 server2 kernel: [982101.745740] vmbr0: port 25(fwpr219p0) entered disabled state
Jun 29 02:58:07 server2 kernel: [982101.746399] device fwln219i0 left promiscuous mode
Jun 29 02:58:07 server2 kernel: [982101.746405] fwbr219i0: port 1(fwln219i0) entered disabled state
Jun 29 02:58:07 server2 kernel: [982101.778993] device fwpr219p0 left promiscuous mode
Jun 29 02:58:07 server2 kernel: [982101.778998] vmbr0: port 25(fwpr219p0) entered disabled state
Jun 29 02:58:08 server2 pvedaemon[50625]: <root@pam> end task UPID:server2:0000C6EF:05DA994A:5D16B797:qmstop:219:root@pam: OK
Jun 29 02:58:10 server2 pvedaemon[28902]: <root@pam> starting task UPID:server2:0000C732:05DA9DCE:5D16B7A2:qmstart:219:root@pam:
Jun 29 02:58:11 server2 kernel: [982106.178282] device tap219i0 entered promiscuous mode
Jun 29 02:58:12 server2 kernel: [982106.271584] fwbr219i0: port 1(fwln219i0) entered blocking state
Jun 29 02:58:12 server2 kernel: [982106.271590] fwbr219i0: port 1(fwln219i0) entered disabled state
Jun 29 02:58:12 server2 kernel: [982106.271819] device fwln219i0 entered promiscuous mode
Jun 29 02:58:12 server2 kernel: [982106.271995] fwbr219i0: port 1(fwln219i0) entered blocking state
Jun 29 02:58:12 server2 kernel: [982106.271999] fwbr219i0: port 1(fwln219i0) entered forwarding state
Jun 29 02:58:12 server2 kernel: [982106.281785] vmbr0: port 25(fwpr219p0) entered blocking state
Jun 29 02:58:12 server2 kernel: [982106.281791] vmbr0: port 25(fwpr219p0) entered disabled state
Jun 29 02:58:12 server2 kernel: [982106.282036] device fwpr219p0 entered promiscuous mode
Jun 29 02:58:12 server2 kernel: [982106.282356] vmbr0: port 25(fwpr219p0) entered blocking state
Jun 29 02:58:12 server2 kernel: [982106.282368] vmbr0: port 25(fwpr219p0) entered forwarding state
Jun 29 02:58:12 server2 kernel: [982106.291570] fwbr219i0: port 2(tap219i0) entered blocking state
Jun 29 02:58:12 server2 kernel: [982106.291575] fwbr219i0: port 2(tap219i0) entered disabled state
Jun 29 02:58:12 server2 kernel: [982106.291895] fwbr219i0: port 2(tap219i0) entered blocking state
Jun 29 02:58:12 server2 kernel: [982106.291898] fwbr219i0: port 2(tap219i0) entered forwarding state
Jun 29 02:58:12 server2 pvedaemon[28902]: <root@pam> end task UPID:server2:0000C732:05DA9DCE:5D16B7A2:qmstart:219:root@pam: OK
Jun 29 02:58:34 server2 pvedaemon[21551]: <root@pam> starting task UPID:server2:0000C7F9:05DAA741:5D16B7BA:qmstop:114:root@pam:
Jun 29 03:00:47 server2 pvedaemon[28902]: <root@pam> starting task UPID:server2:0000CA4A:05DADB3F:5D16B83F:qmstop:201:root@pam:
Jun 29 03:00:58 server2 kernel: [982272.798477] vmbr0: port 4(tap201i0) entered disabled state
Jun 29 03:00:59 server2 pvedaemon[28902]: <root@pam> end task UPID:server2:0000CA4A:05DADB3F:5D16B83F:qmstop:201:root@pam: OK
Jun 29 03:01:30 server2 pvedaemon[28902]: <root@pam> starting task UPID:server2:0000CAEB:05DAEBAF:5D16B86A:qmstop:191:root@pam:
Jun 29 03:01:33 server2 kernel: [982308.252426] vmbr0: port 3(tap191i0) entered disabled state
Jun 29 03:01:35 server2 pvedaemon[28902]: <root@pam> end task UPID:server2:0000CAEB:05DAEBAF:5D16B86A:qmstop:191:root@pam: OK
Jun 29 03:01:42 server2 pvedaemon[28902]: <root@pam> starting task UPID:server2:0000CB1F:05DAF067:5D16B876:qmstart:191:root@pam:
Jun 29 03:01:43 server2 kernel: [982317.823868] device tap191i0 entered promiscuous mode
Jun 29 03:01:43 server2 kernel: [982317.846117] vmbr0: port 3(tap191i0) entered blocking state
Jun 29 03:01:43 server2 kernel: [982317.846121] vmbr0: port 3(tap191i0) entered disabled state
Jun 29 03:01:43 server2 kernel: [982317.846454] vmbr0: port 3(tap191i0) entered blocking state
Jun 29 03:01:43 server2 kernel: [982317.846457] vmbr0: port 3(tap191i0) entered forwarding state
Jun 29 03:01:43 server2 pvedaemon[28902]: <root@pam> end task UPID:server2:0000CB1F:05DAF067:5D16B876:qmstart:191:root@pam: OK
Jun 29 03:04:48 server2 vzdump[35453]: <root@pam> end task UPID:server2:00008A81:05CE6DA8:5D16986F:vzdump:114:root@pam: OK
Jun 29 03:06:38 server2 pvedaemon[50625]: <root@pam> starting task UPID:server2:0000CFA6:05DB6422:5D16B99E:qmstart:201:root@pam:
Jun 29 03:06:39 server2 kernel: [982613.604076] device tap201i0 entered promiscuous mode
Jun 29 03:06:39 server2 kernel: [982613.637308] vmbr0: port 4(tap201i0) entered blocking state
Jun 29 03:06:39 server2 kernel: [982613.637313] vmbr0: port 4(tap201i0) entered disabled state
Jun 29 03:06:39 server2 kernel: [982613.637730] vmbr0: port 4(tap201i0) entered blocking state
Jun 29 03:06:39 server2 kernel: [982613.637735] vmbr0: port 4(tap201i0) entered forwarding state
Jun 29 03:06:39 server2 pvedaemon[50625]: <root@pam> end task UPID:server2:0000CFA6:05DB6422:5D16B99E:qmstart:201:root@pam: OK
Jun 29 03:14:16 server2 pvedaemon[50625]: <root@pam> starting task UPID:server2:0000D513:05DC1710:5D16BB68:qmstop:182:root@pam:
Jun 29 03:14:18 server2 kernel: [983072.270676] vmbr0: port 20(tap182i0) entered disabled state
Jun 29 03:14:18 server2 pvedaemon[50625]: <root@pam> end task UPID:server2:0000D513:05DC1710:5D16BB68:qmstop:182:root@pam: OK
Jun 29 03:14:26 server2 pvedaemon[52339]: <root@pam> starting task UPID:server2:0000D53B:05DC1B13:5D16BB72:qmstart:182:root@pam:
Jun 29 03:14:27 server2 kernel: [983082.108450] device tap182i0 entered promiscuous mode
Jun 29 03:14:27 server2 kernel: [983082.122269] vmbr0: port 20(tap182i0) entered blocking state
Jun 29 03:14:27 server2 kernel: [983082.122272] vmbr0: port 20(tap182i0) entered disabled state
Jun 29 03:14:27 server2 kernel: [983082.122507] vmbr0: port 20(tap182i0) entered blocking state
Jun 29 03:14:27 server2 kernel: [983082.122509] vmbr0: port 20(tap182i0) entered forwarding state
Jun 29 03:14:28 server2 pvedaemon[52339]: <root@pam> end task UPID:server2:0000D53B:05DC1B13:5D16BB72:qmstart:182:root@pam: OK
Jun 29 06:20:03 server2 kernel: [994217.662150] NOHZ: local_softirq_pending 80
Jun 29 06:25:04 server2 liblogging-stdlog: [origin software="rsyslogd" swVersion="8.24.0" x-pid="58402" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Jun 29 07:51:00 server2 kernel: [999674.511432] vmbr0: port 26(tap129i0) entered disabled state
Jun 29 08:01:42 server2 pvedaemon[97235]: <root@pam> starting task UPID:server2:0000188B:05F667C6:5D16FEC6:qmstart:129:root@pam:
Jun 29 08:01:43 server2 kernel: [1000317.669183] device tap129i0 entered promiscuous mode
Jun 29 08:01:43 server2 kernel: [1000317.696240] vmbr0: port 26(tap129i0) entered blocking state
Jun 29 08:01:43 server2 kernel: [1000317.696245] vmbr0: port 26(tap129i0) entered disabled state
Jun 29 08:01:43 server2 kernel: [1000317.696634] vmbr0: port 26(tap129i0) entered blocking state
Jun 29 08:01:43 server2 kernel: [1000317.696645] vmbr0: port 26(tap129i0) entered forwarding state
Jun 29 08:01:44 server2 pvedaemon[97235]: <root@pam> end task UPID:server2:0000188B:05F667C6:5D16FEC6:qmstart:129:root@pam: OK
Jun 29 17:50:27 server2 kernel: [1035640.134524] NOHZ: local_softirq_pending 08
Jun 29 22:23:04 server2 pvedaemon[93703]: <root@pam> starting task UPID:server2:000017A5:06454427:5D17C8A8:qmcreate:221:root@pam:
Jun 29 22:23:05 server2 pvedaemon[93703]: <root@pam> end task UPID:server2:000017A5:06454427:5D17C8A8:qmcreate:221:root@pam: OK

 

[fabian]

Wenn die Ursache sicher nicht ein voll laufender Thin-Pool sein kann, dann bleibt fast nur mehr das Zeroing übrig. Falls die Kapazitäten vorhanden sind, wäre ein Test mit "klassischem" LVM (kein Snapshot-Support!) oder qcow2 (Snapshot-Support, benötigt Directory Storage) interessant.

Die Migrationslogs werden übrigens nicht nach der Migration gelöscht (irgendwann werden alte Logs generell gelöscht, aber erst nach vielen Tausend Einträgen).

 

[chrigiboy]

Hallo,

Leider haben wir derzeit kein Test-System zur verfügung auf welchem wir die beiden verschiedenen Speicherungsvarianten testen könnten. Wir haben uns die Migrationslogs und die Zeitpunkte nochmals angeschaut und sind uns zu 99% sicher dass es am Zeroing liegen muss. Dazu haben wir jedoch noch ein paar Fragen:

1. Beim Import einer VMDK (qm importdisk 200 /path ...) haben wir dieses Problem nicht. Unserer Meinung nach müsste doch beim importdisk Befehl genau das gleiche Problem auftreten da er zuerst eine neue Disk erstellt. Beim importieren einer Disk merken wir jedoch gar keinen Unterschied (Alles läuft ohne Probleme weiter). Nicht so bei der Migration. Weshalb haben wir das Problem beim importdisk nicht ?

2. Was für folgen hätte das deaktivieren von Zeroing genau? So wie ich das verstehe könnte dann beispielsweise eine VM Daten "Wiederherstellen" die einer VM gehörten welche vor einiger Zeit gelöscht wurde. Was ist wenn man nach dem erstellen eines neuen Servers jeweils auf der VM fstrim ausführen würde ?

 

[fabian]

Hallo,

Leider haben wir derzeit kein Test-System zur verfügung auf welchem wir die beiden verschiedenen Speicherungsvarianten testen könnten. Wir haben uns die Migrationslogs und die Zeitpunkte nochmals angeschaut und sind uns zu 99% sicher dass es am Zeroing liegen muss. Dazu haben wir jedoch noch ein paar Fragen:

1. Beim Import einer VMDK (qm importdisk 200 /path ...) haben wir dieses Problem nicht. Unserer Meinung nach müsste doch beim importdisk Befehl genau das gleiche Problem auftreten da er zuerst eine neue Disk erstellt. Beim importieren einer Disk merken wir jedoch gar keinen Unterschied (Alles läuft ohne Probleme weiter). Nicht so bei der Migration. Weshalb haben wir das Problem beim importdisk nicht ?

qm importdisk macht einfach 'qemu-img convert', d.h. single-threaded, falls möglich sparse. D.h. es werden nur die tatsächlich belegten Teile alloziert und mit Nullen beschrieben, dann der eigentliche Inhalt. Alle Teile die in der Quelle schon nur aus Nullen bestehen werden einfach übersprungen/als Löcher vermerkt, und erst wenn diese in Zukunft nach und nach belegt werden wird jeweils dieser neu belegte kleine Teil alloziert und genullt, bevor der eigentliche Inhalt drauf landet.

Live Migration mit lokalen Disks verwendet NBD und Block Migration, potentiell multi-threaded, nicht sparse-aware. D.h. die gesamte Disk wird alloziert und im Falle von LVM-Thin mit Nullen beschrieben, dann die belegten Teile geschrieben, dann falls der Qemu Guest Agent konfiguriert ist ein fstrim gemacht um nachträglich Teile dir nur aus Nullen bestehen wieder zu Löchern zu machen (falls der Agent/das Gast OS das kann, und der Storage das unterstützt).

Das lässt sich mittels "Move Disk" von einer ganz oder großteils leeren VM Disk auf LVM-Thin recht einfach nachvollziehen:
VM offline: qemu-img convert
VM online: Block Migration (ohne NBD/Netzwerk, aber Verhalten ist das gleiche)

im offline-Fall schnell und viel gelesen, aber kaum geschrieben, und somit wenig/keine Last generiert
im online-Fall wird schnell und viel gelesen, und schnell und viel geschrieben, und somit viel Last generiert

2. Was für folgen hätte das deaktivieren von Zeroing genau? So wie ich das verstehe könnte dann beispielsweise eine VM Daten "Wiederherstellen" die einer VM gehörten welche vor einiger Zeit gelöscht wurde. Was ist wenn man nach dem erstellen eines neuen Servers jeweils auf der VM fstrim ausführen würde ?

Das bringt nichts, da LVM-Thin bei fstrim nur komplett ungenützte Chunks freigeben kann, die VM aber Chunks nur teilweise belegen kann & wird (und der Rest des Chunks ohne Zeroing Daten von wann und wem auch immer beinhalten kann).

 

[chrigiboy]

Hallo Fabian.
Danke für deine Erklärungen. Hast du uns einen Tipp was wir machen könnten, damit die Live-Migration ohne Unterbruch funktioniert? Die Dauer der Übertragung spielt uns keine Rolle solange die Systeme online bleiben.

 

[fabian]

Ideal wäre bei so großen VM Volumes wie gesagt ein Shared Storage, um das dauernde Kopieren überhaupt zu vermeiden. Ein anderer lokaler storage wie reguläres LVM (kein thin-provisioning, keine Snapshots) oder qcow2 (beides schon möglich) sollte auch Abhilfe schaffen, ein Wechsel ohne Downtime wird allerdings schwierig, es sei denn es gibt Platz für zusätzliche temporäre Festplatten (dann kann am Node selbst "Move Disk" verwendet werden), oder ihr habt genug freie Ressourcen um jeweils einen Node zu leeren, dort den Storage zu wechseln, und wieder zurück zu migrieren (bei der Livemigration mit lokalen Disken kann die Storageart gewechselt werden, da ja sowieso der ganze Inhalt transferiert werden muss, sh. '--targetstorage' Parameter von 'qm migrate').

 

[chrigiboy]

Also Proxmox ist übelst verbuggt!
Ich habe heute wieder eine Maschine migriert. Quelle und Ziel ist genau das gleiche wie das letzte Mal nur ein Windows anstatt ein Linux client und wieder eine 1 TByte Disk. Es dauerte keine 30 Sekunden bis die Festplatte beim Zielserver erstellt wurde!!!! Bei 2 TByte dauerte es rund 1 Stunde und 40 Minuten beim Zielsystem! Während 1h und 40 Minuten kam es dann eben zu Festplatten ausfällen, Disk Errors, Proxmox ausfällen usw. Doch dieses Mal hat der Server nach gerademal 30 Sekunden bereits damit begonnen die Daten zu kopieren mit Anzeige der Prozentanzahl. So schnell hat er noch nie damit begonnen! Das kopieren dauert jetzt ein klein wenig länger, aber das ist mir egal, Hauptsache die VM's und Proxmox stürzen nicht wieder ab!

Also jetzt geht es plötzlich, wie erwartet. Einfach so?!? Was ist da los? Ein Bug wegen dem Disk Cache? Oder wegen FSTRIM_cloned_disks? VirtIO anstatt SCSI? Oder Clientbetriebssystem abhängig? Warum funktioniert es manchmal und manchmal nicht? Kann mir das bitte einer erklären?

Version bei beiden Systemen: 5.4-6
Der Command:
qm migrate 110 server2 --online --with-local-disks

Hier noch die config vom Server:
acpi: 1
agent: 1,fstrim_cloned_disks=1
autostart: 1
boot: cdn
bootdisk: virtio1
cores: 12
cpu: host
cpulimit: 12
cpuunits: 1000
ide0: none,media=cdrom
kvm: 1
lock: migrate
memory: 20480
name: 110
net0: virtio=66:E42:0F:6A:93,bridge=vmbr0
onboot: 1
ostype: win8
reboot: 1
smbios1: uuid=55103cc7-db8c-4598-aa90-6bdfc2ed0406
sockets: 1
vcpus: 12
vga: vmware
virtio1: local-lvm:vm-110-disk-2,cache=unsafe,size=1000G


Zur meiner Info ID:
ID 111 1h 40 Minuten bis Festplatte erstellt war, Plus ca. 2 Stunden zum kopieren
ID 110 0.5 Minuten bis Festplatte erstellt war, Plus ca. 2.5 Stunden zum kopieren

 

[tom]

Also Proxmox ist übelst verbuggt!

Soweit ich das sehe, gibts hier Probleme mit Caches und Performance von SSD und grundsätzlich taucht die Frage auf, warum man was machen will was nicht empfohlen ist, schon gar nicht für grosse VMs.

Anstatt hier von "üblen bugs" zu reden, schlage ich vor das Problem zu debuggen und den Fehler einzugrenzen - ich sehe hier falsche VM Konfigurationen (cache=unsafe), und es sind wohl noch andere Dinge die nicht optimal sind.

Welche Hardware wird verwendet? (mainboard, CPU, ram), welche SSD in welcher Konfiguration?