| Linux/UNIX Linuxverfechter finden hier Weggefährten. |
Diskussion: KVM - Domain nach Migration lange Zeit unerreichbar im Forum Linux/UNIX, in der Kategorie Operating Systems; Anzeige Hi, nach der Live Migration einer KVM Domain, ist sie recht lange Zeit unerreichbar: Wenn ich von einer Maschine ...
![]() |
| | #1 (permalink) | |
| Senior Member Registriert seit: 26.03.06 ![]() Likes: 16 | Anzeige Hi, nach der Live Migration einer KVM Domain, ist sie recht lange Zeit unerreichbar: Wenn ich von einer Maschine aus demselben Subnet pinge, oft bis zu 50 Pings (erkennbar an der Sequence Number). Ich habe ein Switching Problem in Verdacht. Zuerst aber in wenig zu meinem Setup: Netzwerke: VLAN 0: management VLAN 10: DMZ VLAN 11: Storage VLAN 12: Production ironman.vl.invalid: - 2x 200GB LVM logical volume auf RAID0 - als LUNs über IET (iSCSI Enterprise Target) - IP: 10.10.11.3/24 - hängt in den VLANs 11 und 12 infra.vl.invalid: - routing, dhcpd3, bind9 - hängt in allen VLANs - 10.10.10.1/24 (management) - 10.10.11.1/24 (storage) - 10.10.12.1/24 (production) srw2016.vl.invalid - Switch - führt 4 VLAN Trunks zu host01 und host02 - Trunk führt VLANs 0, 10, 11, 12 host01.vl.invalid / host02.vl.invalid: - debian 6 amd64 - eth0: 10.10.10.11/24 (management) - eth1.11: 10.10.11.11/24 (storage / iscsi) - bond-prod: active/passive mit eth2.12 und eth3.12 - production bridge für Domains mit bond-prod als Uplink - LUNs /dev/sdb und /dev/sdc über open-iscsi - formatiert mit OCFS2 - gemountet nach /shared01 und /shared02 So an sich funktioniert das alles wunderbar. Eben bis auf die Migration. Die Migration selbst dauert mit 512MB ca 4 sec. Nur leider ist das Netzwerk erstmal ne Weile weg. Aus User-Sicht wären 50 Pings im 1 Sec Takt natürlich viel zu viel auch wenn es für TCP Verbindungen noch im grünen Bereich ist. Hier ist beschrieben, wie die Migration ablaufen sollte: Migration - KVM Zitat:
host01: production bridge host02: production bridge ironman: der hängt auch im VLAN12 für die VMs An allen 3 Stellen hätte ich diesen "Broadcast" eigentlich erwartet, habe aber garnichts gesehen! Hat jemand nun noch eine Idee? Ich habe mir schon überlegt ob die Linux Bridges evtl einfach zu lange brauchen um den neuen Port auf Forwarding zu stellen - wäre ja bei STP nicht ungewöhnlich. Allerdings habe ich STP eigentlich ausgeschalten: Code: root@host01:~# brctl show
bridge name bridge id STP enabled interfaces
production 8000.001b214e3f64 no bond-prod
vnet0
root@host01:~#
root@host02:~# brctl show
bridge name bridge id STP enabled interfaces
production 8000.001b214e3f9a no bond-prod
vnet0
root@host02:~# Code: # PRODUCTION NETWORK
auto eth2
iface eth2 inet manual
auto eth2.12
iface eth2.12 inet manual
auto eth3
iface eth3 inet manual
auto eth3.12
iface eth3.12 inet manual
auto bond-prod
iface bond-prod inet manual
slaves eth2.12 eth3.12
bond-mode active-backup
bond-miimon 100
bond-downdelay 200
bond-updelay 200
auto production
iface production inet manual
bridge_ports bond-prod
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
root@host01:~# Grüße serow Geändert von Serow (19.06.11 um 19:38 Uhr) | |
| | |
| | #2 (permalink) |
| Senior Member Themenstarter Registriert seit: 26.03.06 ![]() Likes: 16 | Hi, Problem durch rumprobieren und mag pages lesen gelöst: bridge_fp = 9 gilt nicht nur mit aktiven Spanning Tree, wie ich erst dachte. Den Wert auf 0 gesetzt und ich habe bei der Migration eine Latenzerhöhung von gerade mal 20ms. Grüße serow |
| | |
![]() |
| - Anzeige - | |
| |
| Themen-Optionen | |
| Ansicht | |
| |