Category: VMware

Idag tänkte jag ta upp ett problem jag råkade ut för i mitt hemmalab som resulterade i Error 29113. Bakgrunden är att i hemmalabbet ville jag ha några virtuella ESXi hostar, Domänkontrollant samt vCenter. Eftersom det är en enkel och liten miljö endast tänkt för test/lab så ville jag lägga alla vCenter beroenden på samma server (Single Sign On, Inventory service, Web Client) som vCenter servern. Dessutom ville jag använda Windows vCenter istället för vCenter Server Appliance.

Så vi börjar installation av vCenter server, väljer Simple installation – alla delarna installeras på samma server:

(Bild saknas)

Installationen startar med Single Sign On, som installeras utan problem.

Fortsätter med installationen av Web Client men får felmeddelande om att något gått snett:

(Bild saknas)

Så låt oss titta på de olika alternativen som ovanstående bild visar. Felsökning påbörjas, vi börjar uppifrån och går ner:

-Verify that the certificate file specified in vcsso.properties is valid.

Filen vcsso.properties ligger som standard på en Windows 2008 installation i katalogen:

C:\ProgramData\VMware\VMware VirtualCenter\ssl

Eftersom vCenter ännu inte blivit installerad saknas katalogen helt och ingen fil finns tillgänglig att verfiera. En sökning på disk visar inte heller något resultat, filen finns inte på servern.

(Bild saknas)

-Verify that the clocks on the Single Sign On system and the vSphere Web Client system are in sync.

Eftersom det är en simple install så läggs både Web Client och Single Sign On på samma server, men för säkerhets skull verfierar jag att klockan på domän kontrollanten och vCenter servern är i synk, vilket de är.

-Check the vm_ssoreglog in the system temporary folder for more details on the error.

Vi tar upp filen och kollar innehållet. Filen innehåller en del information:

[2013-10-13 09:57:15,154 main  DEBUG com.vmware.vim.install.cli.RegTool] $Id: //depot/vicore/vicore-2013-rel/regtool/viregtool/src/main/java/com/vmware/vim/install/cli/RegTool.java#4 $
[2013-10-13 09:57:15,156 main  DEBUG com.vmware.vim.install.cli.RegTool] Executing command: checkVersion -d https://VCENTER_VS.vclass.local:7444/lookupservice/sdk –version-number 1.5
[2013-10-13 09:57:15,200 main  INFO  com.vmware.vim.install.impl.RegistrationProviderImpl] Intializing registration provider…
[2013-10-13 09:57:15,741 main  DEBUG com.vmware.vim.install.impl.LookupServiceAccess] Creating VMODL client for LookupService
[2013-10-13 09:57:15,743 main  INFO  com.vmware.vim.install.impl.CertificateGetter] Getting SSL certificates for https://VCENTER_VS.vclass.local:7444/lookupservice/sdk
[2013-10-13 09:57:17,234 main  DEBUG com.vmware.vim.install.impl.CertificateGetter] Establishing socket connection to VCENTER_VS.vclass.local/192.168.0.240:7444. Timeout is 60000
[2013-10-13 09:57:17,566 main  ERROR com.vmware.vim.install.cli.commands.CommandArgumentsParser] Host name may not be null
[2013-10-13 09:57:17,567 main  INFO  com.vmware.vim.install.cli.RegTool] Return code is: InvalidInput
[2013-10-13 09:57:17,940 main  DEBUG com.vmware.vim.install.cli.RegTool] $Id: //depot/vicore/vicore-2013-rel/regtool/viregtool/src/main/java/com/vmware/vim/install/cli/RegTool.java#4 $
[2013-10-13 09:57:17,942 main  DEBUG com.vmware.vim.install.cli.RegTool] Executing command: checkVersion -d https://VCENTER_VS.vclass.local:7444/lookupservice/sdk –version-number 1.5 -c C:\Users\ADMINI~1.VCL\AppData\Local\Temp\1\{0A94097F-6DE2-484D-A2B2-ADAF51CC3FDF}\certs\
[2013-10-13 09:57:17,986 main  INFO  com.vmware.vim.install.impl.RegistrationProviderImpl] Intializing registration provider…
[2013-10-13 09:57:18,564 main  DEBUG com.vmware.vim.install.impl.LookupServiceAccess] Creating VMODL client for LookupService
[2013-10-13 09:57:18,568 main  INFO  com.vmware.vim.install.impl.CertificateGetter] Getting SSL certificates for https://VCENTER_VS.vclass.local:7444/lookupservice/sdk
[2013-10-13 09:57:19,053 main  DEBUG com.vmware.vim.install.impl.CertificateGetter] Establishing socket connection to VCENTER_VS.vclass.local/192.168.0.240:7444. Timeout is 60000
[2013-10-13 09:57:19,396 main  ERROR com.vmware.vim.install.cli.commands.CommandArgumentsParser] Host name may not be null
[2013-10-13 09:57:19,398 main  INFO  com.vmware.vim.install.cli.RegTool] Return code is: InvalidInput

En del av informationen är info och debugrelaterat, men det finns några Error meddelande som säger att Host name may not be null, dock så finns det ju faktiskt ett namn på servern så det kan det väl inte vara? Om vi blickar tillbaka till punkten då servern lades till i MS domänen så fick man ett meddelande som angav att namnet inte var lämpligt (i mitt fall vCenter_VS):

(Bild saknas)

Men i labmiljön använder jag Microsoft DNS server så det borde funka?

Slutligen får man rådet att besöka VMware knowledge base och söka efter feler ”Error 29113”.

Rubriken för KB artikeln är ”Upgrading to vCenter Server 5.1 fails with the error: Certificate already expired”. Eftersom vi inte gör en uppgradering så är problemet inte riktigt relaterat till KB artikeln, men den pekar åtminstone på att man ska verifiera vcsso.properties igen men hänvisar till en annan katalog.

Note: The vcsso.properties file is located at C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool\.

Den visar sig vara lika tom som förra katalogen:

(Bild saknas)

När det ursprunliga felmeddelande klickas bort kommer följande meddelande: Fields cannot be blank.

Och det ursprungliga felmeddelandet presenteras på nytt:

(Bild saknas)

Därefter avinstalleras tjänsten och ett meddelande hänvisar till manuell installation istället:

(Bild saknas)

Så då fortsätter vi med en manuell installation av Web Client och ser om vi kan testa några saker:

(Bild saknas)

Eftersom vi hade ett fel tidigare i vm_ssoreg.log filen som indikerade problem med hostname så gör vi ett test att använda IP adressen till Lookup Service URL istället för FQDN för att se om det kan vara problemet:

(Bild saknas)

Även denna gång misslyckas installationen, men ett nytt felmeddelande visas som hänvisar till KB artikel 29102.

(Bild saknas)

Inte heller det är relaterad till vårt problem, det handlar om att servernamn som innehåller ”port” ersätts med ”portNumber” och föreslår att man inte ska döpa servern med namn som innehåller port (exempelvis en server som döps till ”support” kommer att fallera på grund att någonstans i uppgraderingskoden finns en ”search & replace” funktion som ändrar strängnamn ”port” till ”portNumber” och som en följd blir servernamnet i vårt exempel till ”supportNumber” istället Problem att installera vCenter 5.5: Error 29113 )

To work around this issue when you do not want to upgrade, ensure that vCenter Server and the database server FQDNs do not contain the string port in the name.

Problemet verkar uppenbarligen vara relaterat till någon form av namnuppslag. Även om servernamnet inte var enligt best practise så skulle det ändå inte vara ett problem så länge man använde sig av Microsoft DNS, vilket jag gör. Men för att testa tesen så byter vi namnet på vCenter servern och ersätter understrykningstecknet med ett bindestreck istället (från vCenter_VS till vCenter-VS alltså).

Sen för enkelhetens skull avinstalleras Single Sign On och installeras igen så vi är säkra på att det ändrade namnet är uppdaterat överallt.

Därefter installeras alla tjänsterna utan problem.

(Bild saknas)

Specialtecken i servernamn kan alltså ställa problem som resulterar i inte helt uppenbara felmeddelande. Det man ska undvika då man namnger servrarna är enligt KB artikel 2041856 (som även hänvisar till Microsoft KB artikel 909264) följande:

• comma (,)
• tilde (~)
• colon (:)
• exclamation point (!)
• at sign (@)
• number sign (#)
• dollar sign ($)
• percent (%)
• caret (^)
• ampersand (&)
• apostrophe (‘)
• period (.)
• parentheses (())
• braces ({})
• underscore (_)
• white space (blank)

Under vissa förhållande kan man i vCenter få ett felmeddelande på någon host som meddelar att Quick stat on <host> is not up-to-date. Meddelandet syns oavsett om man ansluter via vSphere client eller Web client mot vCenter Server, däremot får man inte meddelandet om man ansluter direkt mot en host. Det är ett känt problem i vCenter Server 5.5 och för att lösa det krävs att man ändrar i konfigurationsfilen för vCenter, vpxd.cfg.

(Bild saknas)

Börjar med att göra en kopia/backup av vpxd.cfg-filen. Om du kör vCenter Server från Windows hittar du filen i:

C:\ProgramData\VMware\VMware VirtualCenter\

och använder du vCenter Server Appliance finns filen i:

/etc/vmware-vpx/

Öppna sedan vpxd.cfg i din favorit text editor (notepad eller VI) och lägg till nedanstående text någonstans mellan … taggarna:

<quickStats>
<HostStatsCheck>false</HostStatsCheck>
<ConfigIssues>false</ConfigIssues>
</quickStats>

Spara filen och avsluta texteditorn. Därefter startar du om vCenter Server tjänsterna och då är felmeddelandet borta.

Som VMware instruktör vet man att det blir diskussioner vid vissa område när man håller en vSphere kurs. Ett av dessa område som det tveklöst blir diskussioner kring är hantering av tid i en virtualiserad miljö. Har synkar man bäst tiden för sina virtuella maskiner, hur synkar man tiden på sina hostar, vad är best practice och så vidare.

Anledningen att ha att synka tiden är helt enkelt att vi ska kunna lita på att vi ser rätt tid inuti en virtuell maskin eller rättare sagt att operativsystemet och applikationerna ser rätt tid, vissa applikationer kan vara väldigt känsliga om tiden skiljer sig för mycket med omvärlden. Ett exempel är Microsoft Domain Controllers som slutar replikera information om tiden skiljer sig för mycket mellan de olika domänkontrollanterna vilket kan vara ett stort problem men det finns naturligtvis massor av andra exempel.

Vi har två olika sätt att synkronisera tiden för virtuella maskiner:

1. Använda inbyggda verktyg i operativsystemet för att synkronisera tiden med en extern källa
2. Använda VMware tools för att synkronisera tiden inuti den virtuella maskinen med hosten den körs på

Synkning med hjälp av VMware Tools kan sättas via edit settings på den enskilda virtuella maskinen (men det är inte aktiverat per default):

(Bild saknas)

Oavsett vilken av metoderna ovan man använder sig av ska man se till att man endast använder sig av ett sätt, om man använder VMware tools för tidssynkningen avaktiverar man operativsystemets egna metod eller vice versa. De flesta miljöer omfattar ett Microsoft Active Directory vilket även kan användas för tidssynkning, så låt oss säga vi beslutar oss för att använda den virtuella maskinens operativsystem för att sätta tiden korrekt (via Active Directory) – då ska vi naturligtvis se till att vi inte använder VMware tools samtidigt för det också.

Bing, bang, boom då var det klart… Eller? Har vi verkligen sett till att vi inte synkar tiden mellan den virtuella maskinen och hosten nu? Behöver vi då ens bry oss om att synka tiden på våra hostar? Av många olika anledningar ska vi se till att synka tiden på hostarna bland annat för att se till att performance charts visar nyttjandet av resurserna på korrekta tider men även för felsökning. Felsökning i en virtualiserad miljö innebär ofta att vi behöver verifiera olika delar i infrastrukturen: Lagrings-, nätverks- eller servermiljön. Och för att göra felsökningen någorlunda överskådlig och korrelera informationen mellan de olika miljöerna ska vi se till att samtliga komponenter i infrastrukturen har en gemensam källa för tid, annars blir det väldiga problem då vi går igenom de olika loggarna vid felsökning – klockan 09.58, då problemet uppstod, måste vara samma i alla loggarna.

Så det är väldigt viktigt att se till att vi synkar tiden både för hostar och virtuell maskiner, och att vi har en gemensam tidskälla för samtliga komponenter i infrastrukturen. Men låt oss spekulera, om jag inte är intresserad av mina performance charts, jag är inte intresserad av loggfiler – jag har ändå aldrig problem med miljön ju. Så jag väljer att inte synka tiden på mina hostar och på mina virtuella maskiner synkar jag tiden med hjälp av operativsystemets funktion och VMware tools tidssynk är disabled. Ett halvår senare upptäcker jag att tiden skiljer sig väldigt mycket på mina hostar, kanske till och med har olika datum, men detta är väl inget problem för mina virtuella maskiner? Jag använder ju Active Directory för att få rätt tid, så det spelar väl ingen roll att mina hostar inte har korrekt tid?

Den stora frågan är hur fungerar VMware tools tidssynkningsfunktion egentligen? Den ser till att periodvis hämta tiden från hosten och sätter därefter tiden inuti den virtuella maskinen, detta sker som standard en gång i minuten. Så om man avaktiverar VMware tools funktionen så stänger man av funktionen för att periodvis hämta/sätta tiden men det finns andra aktiviteter som initierar en synkning av tiden till hosten. Om man har ”pausat” (suspend) en virtuell maskin så kommer den att synka tiden med hosten då den startas upp igen (resume) – kanske inte ett jättestort problem om man inte använder denna funktion. Men vi har samma beteende på en virtuell maskin då vi flyttar den via vMotion, tar ett snapshot, går tillbaka till ett tidigare snapshot, gör shrink på en virtuell disk eller startar om VMware tools tjänsterna. Detta händer alltså även då VMware tools tidssynkningsfunktionen är avaktiverad!
Därför ska man alltid se till att ha en extern tidskälla uppsatt för både virtuella maskiner och hostar!

Men om vi går tillbaka till ursprungsfrågan, om jag inte vill synka tiden på mina hostar kan jag inte styra hur tiden hanteras då jag gör vMotion, tar snapshot och så vidare? Jo, det går att styra via de avancerade parametrarna på en virtuell maskin.

Markera den virtuella maskinen i ditt inventory och stäng av den virtuella maskinen (inställningarna läses inte in om man bara gör en reboot). Högerklicka den virtuella maskinen och välj Edit Settings, klicka på Options fliken och välj General (under Advanced).

(Bild saknas)

Klicka på Configuration Parameters och klicka på Add Row och lägg till följande information:

tools.syncTime = 0
time.synchronize.continue = 0
time.synchronize.restore = 0
time.synchronize.resume.disk = 0
time.synchronize.shrink = 0
time.synchronize.tools.startup = 0
time.synchronize.tools.enable = 0
time.synchronize.resume.host = 0

Detta behöver alltså göras på varje enskild virtuell maskin, antingen manuellt eller via script, och dessutom måste de virtuella maskinerna stängas ner och startas upp för att inställningarna ska läsas in och användas.

Referens:
Disabling Time Synchonization
Configure Time Synchronization Between Guest and Host Operating Systems

Äntligen har VMware släppt en uppdatering till vSphere 5.1 som löser en del problem som irriterat oss.
En av de första sakerna jag lägger märke till är att nu är äntligen Windows Server 2012 supporterat att köra vCenter på, dessutom stöds även MS SQL 2012 som DB.

Ett annat problem som gäckat oss är omdöpning av virtuella maskiner, i sig inget problem eftersom man under lång tid kunnat döpa om en virtuell maskin (Display name) utan att det påverkar miljön. Problemet ligger i att ”Display name” inte propageras ner till katalog- och filnamn för den virtuella maskinen vilket i en förlängning kan försvåra en eventuell felsökning. Om man förlitar sig på ”Display name” när man felsöker en virtuell maskin som blivit omdöpt och försöker hitta relaterade filer på VMFS datastore så hittar man inte en katalog som stämmer överens namnmässigt. En lösning finns nu åter igen i update 1 för vSphere 5.1 där man helt enkelt kan göra en storage vmotion för att synkronisera namnen på katalog och display name – MEN det kräver att man i advanced settings på vCenter sätter provisioning.relocate.enlabeRename till True.

När vi ändå är inne på VMFS så innehåller update 1 även en förändring på VMFS Heap Size där man nu kan växa Heap Size till 640 MB jämfört med 256 MB tidigare. Detta minimerar eventuella problem att starta upp virtuella maskiner då många, stora virtuella hårddiskfiler är öppna.

I samband med vSphere 5.1 uppdateringen har VMware även släppt uppdatering för SRM och vSphere Replication, både är nu uppe i version 5.1.1

När nu VMware har lanserat sin senaste version av vSphere, som är 5.1, är det några förändringar som gjorts på licens-sidan.

I nästan alla bundlingar, det vill säga Essentials Plus och alla Acceleration kit, ingår numera VMwares appliance för virtuellt SAN (vSphere Storage Appliance) och dessutom ingår även funktionen för att replikera virtuella maskiner mellan hostar (vSphere Replication) också. En annan förändring är att backup funktionen som tidigare gick under namnet Data Recovery har ersatts av en nyutvecklad backupappliance vid namn Data Protection. Data Protection är en lösning utvecklad av VMware tillsammans med EMC som bygger i grunden på Avamar teknologi.

Vad gäller fristående licenser har det tillkommit en variant vilket innebär att det finns totalt 4 stycken att välja mellan:

• Standard
• Standard with Operations Management
• Enterprise
• Enterpris Plus

Skillnaden mellan Standard och Standard with Operations Managment är att i den senare ingår vCenter Operations Management Suite Advanced samt vCenter Protect.

I samtliga fristående licenser (från Standard upp till Enterprise Plus) ingår:

• vSphere Replication
• Fault Tolerance
• Storage vMotion

Och som säkert ingen missat vid det här laget så har VMware valt att slopa vRam licensering dessutom har man tagit bort begränsning på antal kärnor per CPU, detta innebär att det enda man behöver ta hänsyn till är hur många CPU sockets hostarna har!

För att kunna skapa de allra största virtuella maksinerna (tilldela 64 vCPU) krävs Enterprise Plus, med Enterprise kan man tilldela 32 vCPU och alla övriga licenser tillåter 8 vCPU per virtuell maskin.

För mer information:

http://www.vmware.com/files/pdf/vsphere_pricing.pdf