[sage-ka] Virtualisierung als Sparmaßnahme

[Andreas Jellinghaus]

Wenn wir schon bei ESXi sind, eine Frage dazu noch:

wird bei den netzwerk verbindungen nur bridged mode unterstützt,
oder auch (wie von der workstation bekannt) auch nat oder
routed/proxy arp mode (sprich eigene ip für den gast, aber über
die mac des hosts)?

ist die auswahl beschränkt wenn man live-migration können will?

mein ansatzpunkt ist das problem live-migration und arp cache:
wie zieht man einen guest auf einen anderen host, und bekommt
da keine probleme? eine möglichkeit ist eine neue mac für die
IP und diese per broadcast bekannt geben. da gibts aber nichts
standardisiertes, und das hätte diverse probleme, oder?

also bleibt für mich nur die feste mac per netzwerk interface
auf jedem guest, die mit wandert. das setzt schon mal die anbindung
per bridged mode vorraus. da frage ich mich nun aber weiter:
wie ist das verhältnis zwischen switch und host? der switch
muss ja auch seinen internen cache aktualisieren, und die
packete zur gleichen mac an einen anderen host schicken.
wie wird der darüber informiert? reicht es ein packet mit
der guest mac von der neuen quelle aus zu schicken? wäre
das nicht unsicher?

oder brauchtes mehr vertrauen zwischen switch und host, als
man einem normalen serverinterface geben würde? oder gar
routing protokolle (STP was das glaub ich)? und falls der
host "mehr vertrauen" bekommt, wieviel filter etc. sind
in der bridge implementation? kann der guestunfug machen
(arp spooding, arp caches fluten, STP angriffe, und was wir
alles in den letzten jahrzehnten so hatten), oder hat vmware
filter eingebaut, die trotz bridge konfiguration vieles
verhindern (ähnlich wie switches eigentlich transparent
sind, aber in der sicheren konfiguration bei arp fluten
und ähnlichem den port dicht machen können)?

hab ich was übersehen, ist die lösung viel einfacher, und
es braucht so komplexe überlegungen nicht? ansonsten wäre
ich ja froh, wenn vmware aus den problemen der switch
hersteller des letzten jahrzehntes gelernt hätte, und
das alles in vmware realisiert hat. nur skeptisch darf
man schon sein, oder?

ist übrigens ein guter grund zum kommerziellen produkt
zu greifen. beim xen oder kvm oder qemu möchte ich gar
nicht nach den details zu solchen problemen fragen -
da ich bisher null mails dazu auf den mailing listen gesehen
habe, und auch in der doku nie was dazu gesehen habe, denke
ich mal, das sich niemand mit der problematik beschäftigt
hat. höchstens in den kommerziellen management lösungen
von xen oder qumranet/redhat.

Tschüss, Andreas