För att du skall kunna identifiera hur mycket RAM som finns installerat i respektive slot så följer du dessa instruktioner:

1. Logga in på ESXi hosten via SSH eller DCUI.
2. Kör följande kommando: smbiosDump
3. Detta kommer ge dig detaljerad information om Minnet i respektive slot.

Tycker man detta verkar krångligt så kan man naturligt vis även lyfta på locket och göra en okulär besiktning

/Andreas

• Integrerade verktyg för I/O prestandatester
• Levereras som en virtual appliance
• Enkelt att konfigurera och starta I/O-tester på flera värdar
• Visa integrerad prestanda resultat på både gäst och värd nivåer
• Export av prestandaresultat för analys off-site

Verktyget från VMwareLabs finner du här:

http://labs.vmware.com/flings/io-analyzer

”Virtual ethernet card ‘Virtual Ethernet Adapter’ is of type which is not supported.  This is not a limitation of the host in general, but of the virtual machine’s configured OS on this host.”

Vad betyder då detta i klarspråk? Jo, anledningen till denna varning var i detta fall att den virtuella nätverksadapter som var konfigurerad för denna VM ej supporterades av det operativsystem som den virtuella maskinen var konfigurerad för. I detta fall var den virtuella adaptern av typen ”Flexible” (se bild 2) och operativsystemet var konfigurerat som ”Windows Server 2008 32bit” (se bild 3). Denna kombination är alltså inte supporterad.

Om vi tittar på vilka typer av NIC adaptrar som finns att välja på för detta OS (se bild 4) så ser vi klart och tydligt att ”Flexible” inte är med i listan. Lösningen på detta var alltså att lägga till en adapter som stöds och att sedan ta bort den ej supporterade. OBS! Notera alla IP-inställningar innan den gamla tas bort för att kunna konfigurera den nya med de korrekta inställningarna.

Enligt rykten kommer VMware att släppa näste version av sin virtualiseringsplattform vSphere under andra halvan av 2011. Det påstås att vSphere 5 kommer att presenteras under VMworld senare i höst. Detta är ännu bara rykten så det finns inga garantier för detta. Hittade däremot lite uppgifter på vilka nyheter som eventuellt vSphere 5 kan komma att innehålla. Denna lista innehåller en hel del godsaker och det är bara att hoppas att denna information är så sanningsenligt som möjligt. Håll tillgodo!

What’s new in vSphere 5

• Build on the vSphere ESXi hypervisor architecture
• vSphere Auto Deploy combining host profiles, Image Builder and PXE
• Unified CLI framework, allowing consistency of authentication, roles and auditing.
• Support for up to 1 TB of memory
• Support for 32 vCPU’s per VM
• Nonhardware accelerated 3D graphics for Windows Aero support
• USB 3.0 device support
• UEFI virtual BIOS
• Host EUFI boot support
• New GUI to configure multicore vCPUs
• Client-connected USB devices
• Smart card reader support for VMs
• Apple Mac OS X Server 10.6 (Snow Leopard) guest OS support
• Support for up to 512 VMs
• Support for up to 160 Logical CPUs and 2 TB or RAM
• Improved SNMP support
• Storage driven storage delivery based on the VMware-Aware Storage APIs
• Improved version of the Cluster File System, VMFS5
• Accelerator for specific use with View (VDI) workloads, providing a read cache optimized for organizing, handling and deduplicating VDI client images.
• iSCSI user interface support
• Storage APIs – Array Integration: Thin Provisioning enabling reclaiming blocks of a thin provisioned LUN on the array when a virtual disk is deleted
• Swap to SSD
• 2TB+ LUN support
• Storage vMotion snapshot support
• vNetwork Distributed Switch improvements providing improved visibility in VM traffic
• ESXi Firewall protecting the ESXi 5.0 management interface
• A browser-based, fully-extensible, platform-independent implementation of the vSphere Client based on Adobe Flex.
• vCenter Server Appliance
• Inventory Extensibility: providing a manager to monitor partner extensions.
• vCenter Solutions Manager, providing a consistent interface to configure and monitor vCenter-integrated solutions developed by VMware and third parties.
• System message logging enhancements
• Revamped VMware High Availability (HA) with Fault Domain Manager
• All hosts in cluster can be primary nodes
• Cluster also uses shared storage as a channel for heartbeat detection

Apr 13 11:48:32.330: vmx| Powering off Ethernet0
Apr 13 11:48:32.331: vmx| Hot removal done.

Detta bevisar alltså att någon nyttjat funktionen att ta bort nätverksadaptern under skarp drift. Nätverksadaptern visas under ”Safely Remove Hardware” i ”system tray”. För att undvika att detta sker igen så bör man avaktivera denna funktion för den virtuella maskinen genom att sätta parametern devices.hotplug till false enligt följande bild. Det kan vara bra att veta att detta  inte påverkar möjligheten att lägga till/ta bort CPU eller minne under drift utan endast NIC och SCSI adapters.

I denna guide har jag sammanställt den information som jag funnit kring ämnet och metoden som beskrivs är ett rekommenderat tillvägagångssätt från VMware. Tid synkroniseringen av domänkontrollanten sker genom att använda Grupp policy objekt och WMI-filtrering.

Fördelen med denna metod är att korrekta registerinställningar sker per automatik på den primära domänkontrollanten även vid en eventuell migrering av denna roll. Hoppas att denna guide kan komma till nytta när det är dags för virtualisering av ert Active Directory.

Guiden hittar du här: TidSynkVirtuellDC.pdf

För att ta reda på vilken uppdatering hosten kör kan man genom att matcha build nummret mot respektive uppdatering enligt följande tabell.

ESX/ESXi

ESX 4.1 = Build 260247 – Released 13 July 2010

ESX 4.0 Update 2 = Build 261974 – Released 10 June 2010

ESX 4.0 Update 1 = Build 208167 – Released 19 Nov 2009

ESX 4.0 = Build 164009 – Released 21 May 2009

vCenter

vCenter Server 4.1 | 13 Juli 2010 | Build 259021

vCenter Server 4.0 Update 2| 10 JUN 2010 | Build 258672

vCenter Server 4.0 Update 1 | 19 Nov 2009 | Build 208156

vCenter Server 4.0 | 05 May 2009 | Build 162902

• Hur många virtuella maskiner kan jag köra på en host?
• Hur stora LUNs skall jag skapa på mitt SAN?
• Hur många VMs kan jag köra per LUN?
• Hur mycket RAM och CPU skall jag ha i mina hostar?

Hostsize

Det finns naturligtvis inget enkelt svar på dessa frågor och egentligen inte något rätt och fel. Det är ju många faktorer och förhållanden som spelar in och avgör hur man i slutändan fattar ett beslut. När det gäller storleken och hur man skall dimensionera sina hostar när vi talar CPU och RAM så handlar det om att hitta ett lagom förhållande mellan den fysiska hårdvaran och den arbetslast som skall hostas på denna. Större och kraftfullare servrar innebär färre fysiska hostar att drifta och underhålla, men samtidigt medför detta att konsekvenserna av en eventuell serverkrasch blir allt mer allvarlig. Fördelen med fler mindre fysiska hostar är att lasten kan spridas ut på ett mer effektivt sätt och på så vis minimeras de negativa följderna vid ett hårdvarufel. Dessutom fungerar enligt min uppfattning lastbalanseringen (DRS) bättre i en mer balanserad miljö. I de flesta fall är det alltså bättre att skal ut än att skala upp. Oftast vill man ju ha inte belasta sina hostar mer än 70% för att tillgodose kraven för HA vilket på en kraftfullare maskin innebär större resurser som inte nyttjas. Ett exempel på lämplig server i denna klass skulle kunna vara en HP DL380 eller liknande.

pCPU vs vCPU

När vi sedan talar om förhållandet mellan den fysiska servern och de virtuella maskinerna, alltså hur många VMs / ESX host man kan köra så är svaret återigen ”det beror på”. I några fall när du har en mycket kraftfull host och de VMs som hostas har en mycket låg arbetsbelastning så kan man nå förhållanden på ca 60:1 medan du på en mindre kraftfull host och VMs med hög arbetslast kanske enbart når ett förhållande på 10:1 eller mindre. Man brukar generellt räkna med att en mellanklass server med 2 sockets kan nå ett förhållande på ca 16:1 och ca 32:1 för en med 4 sockets med en normal arbetslast på de VMs som hostas. Det gäller att ha koll på antalet virtuella CPUer i dessa sammanhang. Som en tumregel kan man räkna med att kunna köra 4 x vCPU x antalet pCPU. Det skulle på en server med två fysiska fyrakärninga CPUer ge oss 8pCPU x 4 = 32 vCPU.

Lagringdirektiv

För många VMs per LUN kan skapa flaskhalsar på ditt SAN och du kan få problem med metadata låsningar etc. Det är även viktigt att förhålla sig till det underliggande disksystemet och antalet spindlar i det RAID set som levererar lagringen. Här följer några riktlinjer att förhålla sig till:

• Antalet VMs per LUN i genomsnitt: 14 to 16
• För hög I/O belastning, applications: 8 to 10 VMs per LUN
• För medel I/O belastning: 20 to 22 VMs per LUN
• För mycket låg I/O belastning, terminalservrar, VDI-klienter: mer än 100 VMs per LUN

Tänk på att allt som föreslagits här endast är riktlinjer och rekommendationer. Det finns otaliga faktorer som spelar in i dessa sammanhang och det kan skilja mycket från olika miljöer. Det viktigaste är att man tänker till innan man designar sin virtuella infrastruktur för att på så vis slippa de vanligaste prestandaproblemen.

”Creating snapshot
CreateSnapshot failed, vmRef ”320″, timeout ”1800000″, snName ”VEEAM BACKUP TEMPORARY SNAPSHOT”, snDescription ”Please do not delete this snapshot. It is being used by Veeam Backup.”, memory ”False”, quiesce ”True”
A snapshot operation cannot be performed.”

Detta tyder på att backupjobbet som bygger på att en snapshot tas på aktuell VM inte lyckades med den uppgiften. Veeam Backup & Replication som för övrigt är ett strålande verktyg för backup, replikering och återställning hade lyckats att slutföra backupen för alla (ca 30 st) virtuella maskiner utom för just denna. För att hitta källan till detta testade jag att manuellt skapa en snapshot i vSphere klienten på denna VM och fick där följande felmeddelande:

Det var alltså inte möjligt att skapa en snapshot på denna VM trots att det fanns gott om utrymme på de VMFS volymer som den lagrades på. Hittade en KB artikel på VMware.com som förklarar fenomenet. Orsaken till detta är att storleken på en utav de virtuella diskarna för den aktuella maskinen överstiger den storlek som begränsas till ett fast värde beroende på vilken ”blocksize” som den VMFS volym har där den virtuella maskinens ”working directory” husgherar. Låter det klurigt? Jag håller med!

För att klargöra det hela så börjar vi med de storleksbegränsningar för filer som respektive blocksize utgör på en VMFS datastore

Detta betyder att om du skapar en VMFS datastore och väljer en blockize på ex. 1 MB så innebär detta att den inte kan lagra filer större än 256 GB – 512 Bytes. Om vi nu tittar på den VM som var aktuell i detta fall så hade den följande konfiguration:

VM-NAME

Disk 0:0 60 GB lagras på iSCSI-LUN-01 VMFS-blocksize 1 MB

Disk 0:1 300 GB lagras på iSCSI-LUN-05 VMFS-blocksize 4 MB

Disk 0:0 är i detta fall ”default virtual machine directory” vilket innebär att en snapshot inte tillåts att skapas på denna då storleken på snapshoten i teorin skulle kunna överstiga den totala tillåtna storleken för denna datastore (vilket som sagt är 256 GB – 512 Bytes). Detta pga att Disk 0:1 är som ni ser är 300 GB dvs större än tillåtet.

Hur löser man då detta problem?

Alt 1.

Flytta den disk (med storage vmotion) som innehåller maskinens ”working directory” till en datastore med en större  blocksize .  Det är som standard den disk som innehåller ”.vmx” filen som är ”working directory”.

Alt 2.

Flytta endast konfigurationsfilen genom att köra en storage vmotion och endast välja ”.vmx” filen och på så vis byta ”working directory”.

För mer info se KB 1004040

Alt 3.

Ändra ”default virtual machine directory” till en datastore med större blocksize. Detta sker genom att manuellt redigera ”.vmx” filen för maskinen. Genom att göra detta kan man dirigera om alla snapshots till en annan datastore.

För instruktioner se KB 1002929

Mitt tips är att alltid använda sig utav den största blockstorleken (8 MB) konstant när man skapar sina VMFS volymer.

Duncan Epping – YellowBrick:  Block sizes and growing your VMFS

-passthroughAuth -s vc.yourdomain.com

Byt ut ”vc.yourdomain.com” mot namnet eller ip adressen på din vCenter server. Nu har du möjligheten att automatiskt logga in på vCenter servern utan att ange autentiseringsuppgifter.