Kategorie-Archiv: VMware

NetAPP FAS schreibt sehr langsam Veeam reversed-incremental Backup-Jobs

Veröffentlicht am von — Keine Kommentare ↓

Problem

Mit Veeam Backup and Replication geschriebene Sicherung von von virtuellen Maschinen (vmware oder Hyper-V) sind sehr langsam, wenn diese Faktoren zusammenkommen:

  • NetAPP Storage via CIFS
  • Sicherung im Reversed-Incremental Modus
  • Veeam B&R 6 oder 7

Lösung

Die CIFS-Sitzungsdaten in NetAPP Filern sind im Auslieferzustand für Windows 2000, IIS6 und SQL Server 2000 konfiguriert und lassen viele performancekritische Optimierungsmöglichkeiten vermissen, die Veeam nutzt.

Diese Einstellungen haben sich als „best practice“ erwiesen:

options cifs.max_mpx 1124
options cifs.tcp_window_size 2096560
options cifs.neg_buf_size 65535
options raid.mirror_read_plex_pref alternate

ESX = Elastic Sky X, GSX = Ground Storm X – und andere vmware Abkürzungen die niemand kennt

Veröffentlicht am von — Keine Kommentare ↓

Wer hat sich noch nicht gefragt was die Akronyme in den vmware Produkten bedeuten? Laut Duncan Epping sind ein paar Dinge dabei auf die man selber kommen kann, aber wer wusste vorher die richtige Antwort auf die Frage „Was bedeutet die Abkürzung ESX?„. Hier sind die Antworten:

  • FDM = Fault Domain Manager
  • CSI = Clustering Services Infrastructure
  • PAE = Propero Application Environment
  • ESX = Elastic Sky X
  • GSX = Ground Storm X or Ground Swell X
  • VPX = Virtual Provisioning X
  • VPXA = Virtual Provisioning X Agent
  • VPXD = Virtual Provisioning X Daemon
  • VMX = Virtual Machine eXecutable
  • AAM = Automated Availability Manager
  • VIX = Virtual Infrastructure eXtension
  • VIM = Virtual Infrastructure Management
  • DAS = Distributed Availability Service
  • ccagent = Control Center agent
  • vswif = Virtual Switch Interface

Bei den VP*-Produkten muss man wissen, das der VPX-Server der (ur-ur-) Name des heitgen vCenter Servers war. Die Agenten … heissen halt einfach immernoch so. Zudem stellt sich die Frage, was das alleinstehende „X“ im Namen bedeuten soll. Zitat: „according to VMware old-timer Mike Di Petrillo (source is this interview) the X had been added by an Engineer to make it sound ‚technical and cool'“. Frage geklärt.

vSphere Client unter Windows Server 2012/2012R2 installiert ohne Fehlermeldung nicht

Veröffentlicht am von — 1 Kommentar ↓

Problem

Der vSphere Client 5.1 lässt sich auf Windows Server 2012R2 nicht installieren. Es gibt keine Fehlermeldung, sondern das Setup verschwindet beim start der eigentlichen Installation einfach vom Desktop. Im Taskmanager ist der Installationsprozess aber noch zu sehen. vmware-viclient-server2012r2

Lösung

Schuld ist das Fehlen des .NET Frameworks 2.0, was im .NET Framework 3.0 enthalten ist, was wiederum im Windows-Feature .NET Framework 3.5.1 versteckt wurde. Es hilft die Installation des .NET Framework 3.5 Features über den Servermanager -> Rollen und Features hinzufügen -> Weiter -> Weiter -> .NET Framework 3.5\.NET Framework 3.5.

vmware-viclient-server2012r2-net-frameworkSelbstverständlich läuft die Installation danach auch nicht störungsfrei durch, sondern benötigt noch einmal Hilfe beim setzen des ProductLanguage-Schlüssels. Der Installer von Version 4 zu 5 unterscheidet sich hier praktisch nicht.

vmware ESXi 5.x host crasht mit einem Purple screen (E1000PollRxRing oder E1000DevRx)

Veröffentlicht am von — Keine Kommentare ↓

Seit den aktuellsten Patchständen vom ESX5.1/5.5 an tritt dieser Pinkscreen-Fehler gehäuft auf:

@BlueScreen: #PF Exception 14 in world 63406:vmast.63405 IP 0x41801cd9c266 addr 0x0
PTEs:0x8442d5027;0x383f35027;0x0;
Code start: 0x41801cc00000 VMK uptime: 1:08:27:56.829
0x41229eb9b590:[0x41801cd9c266]E1000PollRxRing@vmkernel#nover+0xdb9 stack: 0x410015264580
0x41229eb9b600:[0x41801cd9fc73]E1000DevRx@vmkernel#nover+0x18a stack: 0x41229eb9b630
0x41229eb9b6a0:[0x41801cd3ced0]IOChain_Resume@vmkernel#nover+0x247 stack: 0x41229eb9b6e0
0x41229eb9b6f0:[0x41801cd2c0e4]PortOutput@vmkernel#nover+0xe3 stack: 0x410012375940
0x41229eb9b750:[0x41801d1e476f]EtherswitchForwardLeafPortsQuick@#+0xd6 stack: 0x31200f9
0x41229eb9b950:[0x41801d1e5fd8]EtherswitchPortDispatch@#+0x13bb stack: 0x412200000015
0x41229eb9b9c0:[0x41801cd2b2c7]Port_InputResume@vmkernel#nover+0x146 stack: 0x412445c34cc0
0x41229eb9ba10:[0x41801cd2ca42]Port_Input_Committed@vmkernel#nover+0x29 stack: 0x41001203aa01
0x41229eb9ba70:[0x41801cd99a05]E1000DevAsyncTx@vmkernel#nover+0x190 stack: 0x41229eb9bab0
0x41229eb9bae0:[0x41801cd51813]NetWorldletPerVMCB@vmkernel#nover+0xae stack: 0x2
0x41229eb9bc60:[0x41801cd0b21b]WorldletProcessQueue@vmkernel#nover+0x486 stack: 0x41229eb9bd10
0x41229eb9bca0:[0x41801cd0b895]WorldletBHHandler@vmkernel#nover+0x60 stack: 0x10041229eb9bd20
0x41229eb9bd20:[0x41801cc2083a]BH_Check@vmkernel#nover+0x185 stack: 0x41229eb9be20
0x41229eb9be20:[0x41801cdbc9bc]CpuSchedIdleLoopInt@vmkernel#nover+0x13b stack: 0x29eb9bfa0
0x41229eb9bf10:[0x41801cdc4c1f]CpuSchedDispatch@vmkernel#nover+0xabe stack: 0x0
0x41229eb9bf80:[0x41801cdc5f4f]CpuSchedWait@vmkernel#nover+0x242 stack: 0x412200000000
0x41229eb9bfa0:[0x41801cdc659e]CpuSched_Wait@vmkernel#nover+0x1d stack: 0x41229eb9bff0
0x41229eb9bff0:[0x41801ccb1a3a]VmAssistantProcessTask@vmkernel#nover+0x445 stack: 0x0
0x41229eb9bff8:[0x0] stack: 0x0

Schuld sind Gast-VMs mit dem alten Intel e1000-Adapter darin. Wenn das Gast-Betriebssystem RSS (Receive Side Scaling) nutzt, was praktisch alle Windows-Versionen seit Vista tun, kann dieser Fehler sporadisch auftreten. Blöd ist natürlich, das der vmkernel das nicht verpackt und gleich den ganzen Host sterben lässt.

Lösung: Es gibt mehrere Möglichkeiten. Die sauberste und gesundeste ist, möglichst schnell alle e1000-Karten gegen das vmxnet-Pendant auszutauschen. eine Liste aller Gäste mit e1000-Karte bekommt man von der Shell auf einem Host mit:

root@labhost22# grep -s -i e1000 /vmfs/volumes/*/*/*.vmx

chimney2-300x139Die zweite und aus Performancesicht deutlich weniger schöne Möglichkeit ist, RSS in den Maschinen komplett auszuschalten. Ich hatte persönlich auch schon das Vergnügen mit Hosts, bei denen das TCPChimney auch ausgeschaltet werden musste, weil der Hosts sonst wieder nach 24 Stunden freundlich pink (purple) leuchtete.

Unter Windows (ab 2008):

netsh int tcp set global rss=disabled

und

netsh int tcp set global chimney=disabled

Unter Linux muss man einen Blick in den geladenen Eth-Treiber werfen (modprobe klärt auf), denn RSS und TCP-Offloading sind da Treibersache. Natürlich ist jeder Treiber anders zu konfigurieren (der aus den VMTools kann auch vmxnet, wenn das also ein VM-Treiber ist, stellt einfach die Netzwerkkarte um).