Thomas Teufl

Knowledgebase

Eine unserer Linuxkisten mit Kernel 2.6.5 im VMware-Cluster hat ein Problem mit extrem langsamen Kopiervorgängen per scp. Statt MBytes/s werden nur kBytes/s übertragen. Offensichtlich besteht ein Problem mit dem Flag “TCP Segment OffLoading”, das aber erst im Kernel 2.6.12 gelöst wurde. Gut, dass man dieses Feature abschalten kann:

ethtool -K eth0 tso off

Vielen Dank an r71

  • 1 Comment
  • Filed under: ESX, Netzwerk
  • vSphere 4 und HP Blades

    Unsere Blades HP BL465c zeigen im vCenter ein gelbes Ausrufezeichen und Fehler in der Hardware: “System Board 2 ProcHot Warning limit exceeded”. Laut HP ist das kein Problem, der Fehler kann ignoriert werden:

    The “Warning” message in the VI Client (for ESX 4.0 vSphere Client) is false and can be safely ignored.

    Siehe HP Support Document c01833766

    VMWare-Tools on Linux

    Never(!) forget

    > vmware-config-tools.pl

    > /etc/init.d/network stop
    > rmmod pcnet32
    > rmmod vmxnet
    > depmod -a
    > modprobe vmxnet
    > /etc/init.d/network start

    Linux hat in VMWare-ESX-Clustern ab und an Probleme, wenn das Management die Pfade zum SAN umschaltet. Setzt man die Timeouts für SCSI-Ausfälle nach oben, kann das Betriebssystem diese umgehen. Setzt man diese aber zu hoch, bekommt bereits die Anwendung Probleme, noch bevor es das Betriebsystem merkt…

    Mit diesem kleinen Bash-Script wird dies für alle SCSI-Devices gesetzt:

    SuSE Linux:

    Datei “/etc/init.d/boot.local”

    for i in `ls /sys/block | grep -P ^sd`;do
    echo “120″ > /sys/block/$i/device/timeout
    done

    Debian:

    Datei “/etc/rc.local”

    echo “120″ > $(l -m /sys/block|sed ’s/, /\n/g’|grep “^sd”|awk {’print “/sys/block/”$0″/device/timeout”‘})

    vCenter Management unter OS X

    kodiakBlueBear erstellt eine OpenSource-Software zum Management von VMWares vCenter, Citrix XEN Server und Microsoft Hyper-V (Allerdings habe ich im Package auch noch Hinweise auf AmazonEC2 und Suns Virtualbox gefunden). Weil das kleine Progrämmchen auf Basis von Adobe AIR entwickelt wird, läuft es sowohl unter Windows als auch auf OS X und Linux. Nichts desto trotz soll es den kompletten Funktionsumfang von vCenter enthalten. Selbst an eine Scripting Engine ist gedacht.

    Die Installation ist problemlos, AIR downloaden und installieren, dann das “kodiak*.air” aufrufen, es wird autom. eine “Installation” durchgeführt. Unter Windows gibt es beim Login allerdings Probleme mit den von vCenter erstellen Zertifikaten, auf dem Mac nicht.

    Aufrufen und wundern: Die Ansicht ist komplett anders als sonstige Verwaltungsinstrumente jeglicher Art und etwas gewöhnungsbedürftig. Was jedoch nicht heißen soll, dass es schlecht ist. Vielmehr erkennt man IMHO daran, dass sich die Entwickler Gedanken um eine gute Visualisierung gemacht haben. Es sieht richtig gut aus. Wär definitiv ein schicker und informativer Hingucker auf der Großbildwand im NOC.

    Die Kommunikation mit vCenter benötigt definitiv eine Kabelverbindung. Hatte ich mich doch anfangs noch gewundert, warum das alles so hackt, wenn die Entwickler doch schreiben, es soll alles performanter sein. Da hat mich OS X ausgetrickst, weil es bei mir immer irgendwo eine Netzwerkverbindung findet. Aber über WLAN ists eben nicht so rasant.

    Kodiak sieht bei uns alle Hosts, Networks, Datastores und Ressource Pools, nur die virtuellen Maschinen bekomme ich noch nicht zu sehen. Auch das neu einloggen nach einem Logout funktioniert nicht.

    Noch benötigt man eine Invitation, um das Tool downloaden und testen zu können. Leider sind die ziemlich alle aus.
    Die letzte Version 0.0.4 ist aus Mai 2009, mal sehen, wie es weitergeht. Potential hätte es definitiv.

    siehe BlueBear Kodiak, Kodiak Wiki, Toms Linkliste, Scott Lowe