floekblog

Beim Einsatz der Astaro Security Gateway Virtual Appliance für VMware auf einem VMWare ESXi 5 Hypervisor sind eklatante Performanceprobleme aufgetreten. Die Latenz z.B. beim Aufruf von Webseiten war sehr hoch und alles gefühlt “langsam”. Laut Internet scheint das Problem primär bei der Kommunikation zu virtuellen Maschinen, die auf dem selben ESXi Host laufen, zu aufzutreten. Die Umstellung des Netzwerkkartentyps von “flexibel” auf “e1000” in VMWare behebt das Problem.

Leider scheint die Solaris Portierung von Xen nun endgültig rausgeflogen zu sein. Nach einem Upgrade von Solaris 11 Express auf Solaris 11 gibt es leider weder einen xend noch das Hypervisorfile xen.gz. Um das offizielle Statement hierzu zu finden musste man etwas suchen. Aus http://www.oracle.com/technetwork/systems/end-of-notices/eonsolaris11-392732.html:

xVM Hypervisor
xVM hypervisor, the Oracle Solaris Xen-based hypervisor for x86 systems, has been removed. Oracle offers two x86-based hypervisor solutions for Oracle Solaris users: Oracle VM Server for x86 and Oracle VM VirtualBox. See http://www.oracle.com/virtualization

Schade

Ich verwende einen Browser @work und einen anderen @home. Mittels locationchanger (http://tech.inhelsinki.nl/locationchanger/) möchte ich diesen umschalten, was unter OS X nicht ohne weiteres möglich ist. Ein Wechsel von Firefox auf Safari ginge zwar z.B. so:

defaults write com.apple.LaunchServices LSHandlers "`defaults read com.apple.LaunchServices LSHandlers | sed -e 's/org.mozilla.firefox/com.apple.safari/'`"

Leider muss jedoch anschließend dem System mitgeteilt werden, dass sich hier etwas geändert hat. Hierzu habe ich nichts sinnvolles gefunden. Allerdings gibt es duti (http://duti.sourceforge.net/). Damit ist es ganz einfach:

Safari:

/usr/local/bin/duti -s com.apple.safari http
/usr/local/bin/duti -s com.apple.safari https

Firefox:

/usr/local/bin/duti -s org.mozilla.firefox https
/usr/local/bin/duti -s org.mozilla.firefox http

Leider musste ich immer wieder feststellen, dass ZFS sehr (und ich meine sehr) Performance hungrig ist. Dies führt immer wieder dazu, dass die Performance der VMs die im xVM laufen beeinträchtigt wird. Workaround: PIN der Dom0 CPU auf einen Core und Nutzung der verbleibenden Cores für die VMs. Dies geht im laufenden Betrieb so:


xm vcpu-set Domain-0 1 # Nur eine vCPU für die Dom0
xm vcpu-pin Domain-0 0 0 # Diese eine vCPU soll nur auf Core 0 laufen
xm vcpu-pin VM all 1-3 # Die vCPU(s) der VM sollen nur Cords 1-3 nutzen


Erfreulicherweise bekommt die libvirt dies auch gleich mit und fügt ein <vcpu cpuset='1-3'>1</vcpu> in die XML Config mit ein.

Damit die Dom0 nach einem Reboot mit einer vCPU und nur auf Core 0 läuft müssen dem Hypervisor die Optionen dom0_vcpus_pin=true dom0_max_vcpus=1 mitgegeben werden.

Leider musste ich diese Tage ein paar Einschränkungen des ZFS Pools mit dem root Dateisystem meines Servers feststellen. Aktuell verwende ich zwei gespiegelte Platten für diesen Pool. Erster Punkt: Schreiben ist aus unerfindlichen Gründen langsam. Mehr wie 2-3 MB/s gehen nicht. Daher war der Plan den Spiegel um zwei weitere Platten zu erweitern (Stripped Mirror). Anscheinend geht das aber nicht. Man kann den Root Pool nur zu einem dreifach Spiegel erweitern. Das Anhängen eines weiteren Mirrors aus zwei Platten wird nicht erlaubt und schlägt mit der Meldung
“cannot add to ‘rpool’: root pool can not have multiple vdevs or separate logs”
fehl. Somit macht es für mich keinen Sinn den Root Pool intensiver zu Nutzen. Man braucht immer einen zweiten Pool.