Onderwerp: [xen] migratie brengt netwerk problemen in DomU

WHT'ers, ik zit hier met het volgende probleem:
ik heb een testopstelling met 2 servers met gbit crosslink er tussen voor replicatie/migratie. Beide machines beschikken over CentOS 5 volledig up2date en Xen uit de repository (3.0.3). Tevens maak ik gebruik van DRBD8.2 en de Xen kernel 2.6.18. Nu heb ik een virtuele machine gemaakt, eveneens CentOS 5, die ik wil migreren van node1 naar node2. Dus, ik 'create' de VM op node1, maak verbinding via SSH en doe binnen de VM een ping naar google.nl De naam resolved, en ik krijg een keurig antwoord. Nu migreer ik naar node2, dat gaat perfect en is binnen een paar ms gedaan. De ssh sessie is nog steeds open, dus dat is allemaal ok. Nu ping ik weer naar google, de naam wordt keurig omgezet naar een IP, maar het antwoord is niet juist:

Code:

[root@vm1 ~]# ping www.google.nl
PING www.l.google.com (64.233.183.99) 56(84) bytes of data.
64 bytes from nf-in-f99.google.com (64.233.183.99): icmp_seq=1 ttl=249 time=0.000 ms

Tevens verneem ik dat de koeler op de CPU het ineens een stuk drukker krijgt...
Een wget wordt voor migratie perfect afgehandeld, maar na de migratie laat ook die het afweten. Hij laat geen voortgang zien/lijkt te hangen waarna dit resultaat komt:

Code:

[root@vm1 ~]# wget www.kdiss.com/100mb.bin -O /dev/null
--09:59:10--  http://www.kdiss.com/100mb.bin
Resolving www.kdiss.com... 193.138.206.121
Connecting to www.kdiss.com|193.138.206.121|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[=======================================================================>] 104,857,600 --.-K/s   in 0s

09:59:10 (48.8 GB/s) - `/dev/null' saved [104857600/104857600]

Als ik nu weer terug migreer is er niets aan het handje en werkt het allemaal weer vlekkeloos.

Nu heb ik al vernomen dat de reactie tijd na een migratie verkort wordt door vanuit beide Dom0's een ping te laten lopen voor/tijdens de migratie, en tevens is de ping vanuit de VM na ~1minuut wel in orde...

Weet iemand een oplossing hiervoor?

Hier heb ik er ook last van.

Is het bij jullie ook zo dat als je de VM pingt(tijdens de live migratie), deze ook ongeveer voor 1 minuut geen antwoord terug geeft?

In een enkel geval, werkt het wel goed, ik heb echter nog niet kunnen achterhalen waar dit aan ligt.

Ik ga dit topic in de gaten houden.

klopt, en de oplossing daarvoor is dus het pingen vanuit (de ontvangende) Dom0.

edit:

kleine detail, maar het ergste is dus nog wel dat de SSH sessie wel behouden blijft en dat ook de webserver geen problemen heeft :|

edit2:
dit komt er trouwens als kernel message (dmesg) in de VM:

Code:

netfront: device eth0 has flipping receive path.

Ben er nog niet helemaal uit wat dit doet..

Oorspronkelijk geplaatst door SDGM

Hier heb ik er ook last van.

Is het bij jullie ook zo dat als je de VM pingt(tijdens de live migratie), deze ook ongeveer voor 1 minuut geen antwoord terug geeft?

In een enkel geval, werkt het wel goed, ik heb echter nog niet kunnen achterhalen waar dit aan ligt.

Ik ga dit topic in de gaten houden.

Heeft dit niet te maken met verschillende (arp) caches ?

Oorspronkelijk geplaatst door Mikey

Heeft dit niet te maken met verschillende (arp) caches ?

waarom kan hij dan wel resolven? (ping naar de Dom0 geeft hetzelfde resultaat trouwens)

Oorspronkelijk geplaatst door KDISS

waarom kan hij dan wel resolven? (ping naar de Dom0 geeft hetzelfde resultaat trouwens)

Ik neem aan dat SDGM van buitenaf probeert. Dat zou kunnen verklaren waarom hij hem 1 minuut niet kan bereiken.

Jij resolved van binnen uit ?

Heb je de mac addressen volgens de eisen van Xen aangemaakt? Dit gaf hier eerst ook wat vreemd netwerk gedrag.

Oorspronkelijk geplaatst door Mikey

Ik neem aan dat SDGM van buitenaf probeert. Dat zou kunnen verklaren waarom hij hem 1 minuut niet kan bereiken.

Jij resolved van binnen uit ?

ik werk inderdaad op een lan, 10.0.0.0/24 De router/dns server zit daar dus in, evenals beide nodes en de VM.
MAC adressen zijn aangegeven in de vm1.conf:

Code:

vif = [ "mac=00:16:3e:7e:86:0d,bridge=xenbr0,vifname=vm1" ]

Ik zit ook op een lan 192.168.x.x, bij het pingen vanaf de vm gebeurt hier precies het zelfde. Of het pingen naar de dom0 helpt ga ik straks even testen.

Ook heb ik netjes de mac adressen opgegeven in mijn conf file.

Bij mij gaat het trouwens ook om CentOS 5 en Xen 3.0.3

dan is mijn ideeen bus op moment even leeg

Oorspronkelijk geplaatst door Mikey

dan is mijn ideeen bus op moment even leeg

geen probleem

we proberen de quake3 gameserver demonstratie na te bouwen, en dat werkt errug goed. Alleen kan ik maar 1x migreren, want weer terug brengt mij dus de problemen... Tijdens de migratie krijgen de clients 1x kortstondig te zien "connection interupted" en daarna spelen ze vrolijk verder. Heel mooi om te zien, maar het werkt maar 1x dus...

edit:

hoe zo'n delay zit er trouwens in het posten van iets naar de xen-users mailinglist en het daadwerkelijk terug zien op http://lists.xensource.com/archives/...05/index.html?

ik heb zojuist Xen 3.2 geinstalleerd via deze link: http://xen.org/download/dl_32rhel5.html

ziet er stukken beter uit alleen jammer dat het dus niet supported is vanuit CentOS...

quake3 server laat nu het volgende zien:
create op node2, game binnen gaan en spelen gaat prima
migreren naar node1, 1seconde connection interrupted daarna prima
migreren terug naar node2, 2 seconden interrupted en dan na nog eens 2 secs weer een 2/3 secs interrrupted.

Nog steeds niet 100% ok, maar stukken beter dan met Xen 3.0.3

[small]tijden hierboven even met factor 10 omhoog graag [/small]

goed, redelijk irritant dat de edit knop weg is :|

dit even ter vervanging van bovenstaande:
--------------------
quake3 server laat nu het volgende zien:
create op node2, game binnen gaan en spelen gaat prima
migreren naar node1, 4seconde connection interrupted daarna prima
migreren terug naar node2, 8 seconden interrupted dan 1sec ok en dan na nog eens 6 secs weer interrrupted waarna het weer ok is.

Nog steeds niet 100% ok, maar stukken beter dan met Xen 3.0.3

[small]tijden hierboven even met factor 10 omhoog graag [/small]

kleine update, het probleem doet zich nu ook ineens voor op een ander systeem waar livemigratie niet van toepassing is.

Schets:

in Dom0 even een ntpdate gedaan, vervolgens terug naar een DomU webserver en daarin gaat de ping eveneens dood met 0.000ms Wederom CentOS 5 met Xen uit de repo. Kortom, die Xen 3.0.3 zit toch iets mis in

edit:
die netfront melding van hierboven is ook aanwezig, dus dat staat los van het livemigratie gezeur en is een generiek Xen iets.