Vill du blir certifierad på VMware?

Som de flesta företag i IT branschen erbjuder även VMware ett antal olika certifieringar. Det finns för alla nivåer, från de grundläggande till det absolut mest avancerade. Det finns tre olika inriktningar eller lösningsområde som man kan certifiera sig inom: Datacenter Virtualization, Cloud och Workforce Mobility. De flesta har 4 olika nivåer man kan certifiera sig på:

VCA – VMware Certified Associate
VCP – VMware Certified Professional
VCAP – VMware Advanced Professional
VCDX – VMware Design Expert

Inom VCAP certifieringen finns dessutom två olika certifieringar, ett Administrations- och ett Designcert. Administrationscertet skiljer sig från de övriga genom att man praktiskt visar att man kan de olika produkterna. Man ansluter till ett testmiljö i USA och skapar virtuella maskiner, löser problem och så vidare baserat på scenarior eller frågor man får.

VCP, VCAP och VCDX är certifieringar som kräver ganska mycket tid och investeringar men om man vill komma igång och få sin första officiella titel som VMware Certified så är det enkelt att komma igång. VCA certifieringen består av gratis E-learning kurs på webben och därefter genomför man en certifiering hos Pearson-vue online.

För att registrera sig för en utbildning går man den sida som lockar mest:
VMware Certified Associate – Data Center Virtualization (VCA-DCV)
VMware Certified Associate – Cloud (VCA-Cloud)
VMware Certified Associate – Workforce Mobility (VCA-WM)

Man lägger till utbildningen genom att klicka på ”Add to myEnrollment”.

För att sedan skriva certet måste man först begära åtkomst som man gör på någon av nedanståend länkar och välja ”Register for the exam”:
VMware Certified Associate Exam- Data Center Virtualization (VCA-DCV) 
VMware Certified Associate Exam- Cloud (VCA-Cloud) 
VMware Certified Associate Exam- Workforce Mobility (VCA-WM)

Därefter kommer det att skickas ett bekräftelsemail till dig vilket kan ta upp till en timme.

Nästa steg är att boka in certet via Pearson Vues hemsida: www.pearsonvue.com/vmware/schedule

Fram till och med 31 januari kan du genomföra VCA certet med 50% rabatt, det enda du behöver göra är att ange följande Voucher / Promo code vid registreringen: VMRT4A4F9976

Så passa på att blir certifierad på VMware – helt kostnadsfri utbildning och 50% rabatt på certet! Dessutom, har du lust kan du få rabatt på samtliga 3 VCA cert!

ESXi som en virtuell maskin i din test/labbmiljö?

Är du som jag fullständigt uppslukad av VMwares olika produkter? Så pass mycket att du till och med har en labb miljö hemma eller på kontoret där du provar olika produkter i en ”skyddad” miljö? I så fall har jag goda nyheter till dig!

Jag brukar sätta upp några ESXi hostar som virtuella maskiner som därefter skapar ett kluster som jag sedan kan labba med VMware View, Operations Manger, SRM, vCloud Director och så vidare utan att påverka något annat. Oavsett om du kör din labb miljö direkt ovanpå vSpheremiljön eller via vCloud Director kan du få en isolerad labbmiljö. Det finns lite olika vägar för att sätta upp labbmiljön beroende på hur automatiserat man vill ha det; Från att göra alla installationer manuellt till att gå via templates och till att använda utomstående lösningar som exempelvis AutoLab och Ultimate Deployment Appliance.

Man kan exempelvis lägga de olika labbmiljöerna (View, vCloud, vSphere osv) i olika vApps som innehåller alla komponenter exemeplvis minst 2 hostar, vCenter Server, NAS server, Domänkontrollant. Fördelen med en vApp är att du startar alla komponenterna i rätt ordning och man behöver bara starta vAppen, inte de olika virtuella maskinerna individuellt. Problemet uppstår däremot när man ska stänga ner vAppen, nedstängningen utförs med hjälp av VMware tools om man vill ha en ”clean” shutdown. Saknas VMware tools får man nöja sig med att den virtuella maskinen gör en poweroff. Nu har dock VMware släppt en ny fling, en fling är ett verktyg som kan användas osupporterat för att förenkla olika funktioner, som faktist gör det möjligt att installera (valda delar av) VMware tools i en ESXi-host och därmed gör det möjligt attt stänga ner en virtuell maskin på ett korrekt sätt.

Hur går man då tillväga för att installera VMware tools i ESXi hosten? Det är bara att följa instruktionerna här under:

Instructions

VMware Tools for Nested ESXi can be installed on any ESXi 5.x guest. This Fling is packaged as a VIB that can be installed using the esxcli command from the guest’s ESXi shell (which can be enabled in the DCUI under Troubleshooting Options).

There are two methods in which you can install the VIB:

Option 1 – Download VIB and upload to an ESXi datastore:

Download http://download3.vmware.com/software/vmw-tools/esxi_tools_for_guests/esx-tools-for-esxi-9.7.0-0.0.00000.i386.vib and upload to an ESXi datastore

esxcli software vib install -v /vmfs/volumes/[DATASTORE]/esx-tools-for-esxi-9.7.0-0.0.00000.i386.vib -f

Option 2 – Install directly from VMware.com (requires internet access from ESXi host):

esxcli software vib install -v http://download3.vmware.com/software/vmw-tools/esxi_tools_for_guests/esx-tools-for-esxi-9.7.0-0.0.00000.i386.vib -f

To uninstall the VIB:

esxcli software vib remove -n esx-tools-for-esxi

Länkar:
AutoLab: http://www.labguides.com/autolab
Ultimate Deployment Appliance: http://www.ultimatedeployment.org/
VMware tools for nested ESXi: http://labs.vmware.com/flings/vmware-tools-for-nested-esxi

VMware vCenter 5.5 startar inte efter omstart

Efter en serverkrasch vägrade VMware vCenter starta igen automatiskt efter uppstart av servern. Vid närmare kontroll visar det sig att några tjänster inte startat som planerat nämligen VMware VirtualCenter Server och VMware VirtualCenter Management Webservices bland annat. Dessutom är inte heller VMware Inventory Service igång. Ingen av tjänsterna går att starta manuellt förutom VMware vSphere Profile-Driven Storage Service som också var stoppad.

Event ID 1000 loggas i eventloggen varje gång man försöker start VMware VirtualCenter tjänsten manuellt i applikationsloggen och Event ID 7024 loggas i Systemloggen. Omstart av tjänsterna i korrekt ordning  verkar heller inte lösa problemet.

Det verkar vara ett problem relaterat till inloggning vid första anblicken, Identity Managment Service och Secure Token Service stängs ner och startas om (Identity Management Service startas först sen STS). Ingen lycka… Dags att kontrollera vpxd.log lite noggrannare och se om där kan finnas några ledtrådar.

I vpxd.log loggas fel relaterade till databasen:

[00312 error 'utilvpxdVdb'] [VpxdVdb::SetDBType] Encountered login error. Subsequent connection attempt failed: 28000

Dags att testa ODBC kopplingen alltså, vid testinloggning via ODBC managern så får man fel:

Microsoft SQL Server Native Client Version 10.50.2500
Running connectivity tests…
Attempting connection [Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user ‘VCENTER\Administrator’. [Microsoft][SQL Server Native Client 10.0][SQL Server]Cannot open database ”VIM_VCDB” requested by the login. The login failed.
TESTS FAILED!

Så uppenbarligen något problem med inloggning mot databasen.

När man öppnar databasen i SQL Server Management Studio så är databasen märkt med en gul varningstriangel och ett förtydligande i form av texten ”Suspect”. En reperation av databasen senare och VMware VirtualCenter Server tjänsten startar som den ska och vi är tillbaks till en fungerande miljö.

VMworld Barcelona 2013 dag 1

Nu har VMworld startat i Barcelona, eventet är större än någonsin enligt rykte fler än 8500 deltagare.

Mycket av den första keynoten handlade om End User Computing, bland annat annonserades Horizon View 5.3 men även att desktop as a service är ett vädigt viktigt område, och det sammanhanget meddelande man även att VMware köpt företaget Desktone.

Några andra produkter som lanserades var vCloud Automation Center 6.0, logInsight 1.5, IT Business Manager.

VMware vCloud Hybrid Service lanserades i augusti som en tjänst för att hantera hybrid moln, idag lanserades ett europeiskt datacenter placerat i UK.

Problem att installera VMware vCenter 5.5: Error 29113

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)

VMware vSphere 5.5 felmeddelande: Quick stats on ”host” is not up-to-date

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.

Är VMware vCloud Automation Center 5.2 bara för din vSphere-miljö?

Vänta nu, vad är vCloud Automation Center först och främst? Det är ett verktyg som hjälper dig med funktioner som exempelvis en self-service portal för beställning av nya maskiner, oavsett om de är fysiska servrar som du managerar via HP iLO- eller Dell iDRAC-kort till exempel, de kan naturligtvis även vara virtuella och det spelar ingen roll vilken hypervisor du använder – du kan rulla ut maskinerna till vSphere, Hyper-V, XenServer eller KVM om du vill. Du kan även rulla ut dina maskiner till ett moln någonstans, ett VMware vCloud moln som kan vara privat eller publikt eller varför inte till Amazon EC2? Hela vägen genom processen har du möjlighet till att ha en godkännande-kedja som måste följas om du vill.

Och för att återgå till frågan i rubriken: Nej, det är den absolut inte som du precist läste. Har du en 100 % virtuell miljö baserad helt på VMware vSphere? Grattis, din miljö är förmodligen ganska enkel att hantera och managera. Men hur ser dina processer ut för exempelvis rulla ut nya tjänster eller för tester? Här börjar det bli lite mer avancerat att hantera och automatisering blir en naturlig del i processerna.

Eller du kanske har, som de flesta organisationer, en blandad miljö där du har både fysiska och virtuella servrar, du kanske använder Microsoft Hyper-v eller Citrix XenServer till och med. Då är VMware vCloud Automation Center kanske något för dig att titta närmare på. vCloud Automation Center är alltså en produkt du använder oavsett vilken plattform du använder: VMware vSphere, VMware vCloud, Microsoft Hyper-V, Citrix XenServer, Citrix Provisioningserver, KVM, fysiska servrar eller publika moln.

Ett annat område som vCloud Automation Center hjälper till med är inom Governance, där governance styrs via policies snarare än via personer vilket hjälper till att effektivisera och samtidigt reducera tiden för att sätta igång nya tjänster. Verktyget låter dig sätta upp tjänster Infrastructure as a Service och Platform as a Service:

(Bild saknas)

Man har alltså en väldigt stor frihet var man vill lägga sina maskiner baserat på en kost-modell exempelvis där man placerar lågprioriterade

Jag har vCloud Director i min miljö och hörde att den kommer försvinna?

Under VMworld i USA för någon månad sedan annonserades att vCloud Director kommer att försvinna som fristående produkt, vissa funktioner kommer att flyttas ”ner” till vSphere och vCenter plattformen och andra funktioner integreras i vCloud Automation Center.

(Bild saknas)

Rent licensmässigt kommer vCloud Director att flyttas in under vCloud Suite licensen som även kommer att innehålla vCloud Automation Center. Om du idag har en fristående vCloud Director licens kommer VMware att använda ett ”Fair Value Conversion”-program för att uppgradera dina licenser.

VMware vCloud Suite 5.5 nu tillgänglig

Nu är äntligen VMware vCloud Suite tillgänglig för nedladdning. I vCloud Suite ingår en lång rad produkter förutom vCloud själv så omfattas även vSphere, vCenter, SRM osv. Filerna hämtas från VMwares nedladdningssida: http://www.vmware.com/downloads

När det släpps en uppdatering krävs ofta även att befintliga licensnycklar uppgraderas till den nya versionen, så är dock inte fallet med vSphere 5.5 och vCenter 5.5. Dina befintliga licensnycklar ska fungera utan någon uppgradering. http://kb.vmware.com/kb/2014295

VMworld 2013 är igång

VMworld har nu startat med buller och bång i San Francisco. För 10 året i rad öppnar VMware portarna för kunder, partners och leverantörer till ett evenemang utan dess like. Deltagarantalet beräknas i år komma upp till 21 000 deltagare! Förutom att leverantörerna slåss om att visa alla sina nya produkter ute på demogolvet så presenterar också VMware många nyheter inom sina olika produktlinjer och dessutom helt nya produkter.

VMworld 2013

Bland annat har man lanserat den nya versionen av vSphere och vCloud Suite 5.5 som bjuder på en lång rad nyheter och förbättrade funktioner. Listan av det som annonserats idag är:

  •  vSphere 5.5
  • vCloud Suite 5.5
  • VMware vCloud Hybrid Service (vCHS)
  • vCloud Director 5.5
  • Single Sign On 2.0
  • vSphere Data Protection Advanced
  • vSphere Replication 5.5
  • Site Recovery Manager 5.5
  • vCloud Planner 1.0
  • En ny serie certifieringar inom VMware Certified Associate familjen.
  • VMware NSX
  • Virtual SAN or VSAN 1.0
  • vCenter Orchestrator 5.5
  • vCloud Networking and Security 5.5
  • vCenter Server Heartbeat 6.6

Låt oss titta på några av nyheterna lite mer i detalj.

Single Sign-On (SSO)

Single Sign-On har grundligt uppdaterats, i princip är SSO helt omskriven för att nu vara optimerad både för små och stora organisationer. En del av nyheterna i SSO är bland annat:

  • Support för alla Active Directory arkitekturer:
    • en-vägs och två-vägs truster
    • Multi och single forest
  • Native High Availability
  • Fortsatt support för local authentication där det krävs
  • Ingen manuell databaskonfiguration

vCenter

Den kanske största förändringen för vCenter handlar om vCenter Server Appliance (VCSA), det vill säga den förpaketerade virtuella maskinen med vCenter redan installerad på en Linux VM. Tidigare hade den inbyggda databasen på VCSA samma begränsning som om man använde SQL Server Express – det vill säga max 5 hostar eller 50 virtuella maskiner. Numer stödjer den rejält många fler hostar och VMs – 500 hostar och upp till 5000 virtuella maskiner.

vSphere

Licensmässigt har inte mycket hänt. Inga funktioner har flyttas till lägre licensnivåer tyvärr, samma pris för licenserna som tidigare. En skillnad som noterats är däremot att man tagit bort begränsningen på vCPUs för virtuella maskiner, i vSphere 5.1 var Essentials/Standard låst till max 8 vCPU, Enterprise till 32 vCPUs och Enterprise Plus till 64 vCPUs. Nu kommer samtliga licensnivåer att kunna hantera upp till 64 vCPUs. vSphere version 5.5 kommer att ståta med en rad förbättringar och en hel del nya funktioner, som vanan trogen placeras i Enterprise Plus licensen. Den enda skillnaden är gratis varianten, vSphere Hypervisor, som fortfarande är låst till 8 vCPUs.

App HA

Med vSphere App HA får man hög tillgänglighet inte bara på virtuella maskiner utan även applikationerna inuti. Även om vSphere HA kan skydda dina virtuella maskiner genom att starta om din VM så är funktionen inte applikationsmedveten vilket innebär att man inte kan upptäcka och åtgärda fel i applikationer. vSphere App HA kan däremot hjälpa till med upptäckt och åtgärd av detta. Huvudsakliga funktioner:
1. Autodiscover av applikationstjänster och deras status
2. Skapa åtgärdspolicy med 3 enkla klick
3. Säker omstart av VM (via HA API) om applikationen inte lyckas starta om
4. Integration med vCenter alarm

De tjänster som för initialt stöds är begränsade till:
MSSQL 2005, 2008, 2008R2, 2012
Tomcat 6.0, 7.0
TC Server Runtime 6.0, 7.0
IIS 6.0, 7.0, 8.0
Apache HTTP Server 1.3, 2.0, 2.2

VMFS

Denna version av vSphere stödjer nu virtuella hårddiskfiler (vmdk filer) större än 2TB. Man har nu möjighet att skapa virtuella hårddiskfiler strax under 64TB i storlek vid behov. vSphere version 5.5 och VMFS 5 krävs för att kunna skapa större diskar än 2TB.

Virtual SAN beta

Virtual SAN är en mjukvarubaserad lagringslösning inbyggd i hypervisorn som nyttjar hostens lokala diskar (SSD och HDD) och förvandlar dessa till en gemensam lagringspool för alla hostar. Det som lanserades idag är en publik beta av Virtual SAN.

Virtual SAN tillhandahåller följande funktioner:
• Automated Storage Management via Intelligenta VM baserade policys
• Dynamisk skalbarhet för att utöka lagring och beräkning dynamiskt vid behov
• Integrerad med vSphere och manageras via vCenter
• Inbyggd tillgänglighet med skydd för flera hårdvarufel
• Ögonblicklig provisionering av lagring utan komplexa arbetsflöden

Krav
• Minst 3 vSphere hostar med lagring
• Kombination av SAS/SATA HDD & SSD; minst 1 SSD och 1 HDD i varje host som bidrar till lagringen i klustret
• SAS/SATA RAID Controller: Måste arbeta i “pass-thru” eller “HBA” mode
• ESXi boot: SD kort/USB/SATADOM föredras (ESXi boot partition och Virtual SAN kan inte finnas på samma SSD/HDD)
• Nätverk: 10G (föredras)

 

vFlash

Med vFlash får man tillgång till följande:
• Virtualisering av flera flash enheter som hanteras som en pool
• Hypervisorbaserad lösning – Inget behov av agenter i den virtuella maskinen eller någon annan modifiering av gäst OSet eller applikationen
• Accelererar applikationsprestanda genom en write-thru cache
• Detaljrik kontroll med hjälp av per-vmdk caching
• Support för DRS-baserade vFlash reservationer
• Möjlighet att flytta cache med vMotion tillsammans med den virtuella maskinen
• Integration med vSphere HA
• Support för alla sorters datastores – NFS, VMFS och RDM’s

 

Web Client

Web Clienten har uppdaterats först och främst med management i fokus. Fler sökfilter och en ny flik för nyligen använda objekt, ”recent objects”, gör det lättare för administratörer att hitta och managera sina objekt snabbare. Man har även gjort produkten mer skalbar och även förbättrat prestandan en hel del.

vSphere Replication

vSphere Replication har uppdaterats med exempelvis dessa nya funktioner:
• Möjlighet att rulla ut nya appliances för replikering mellan cluster och miljöer utan delad lagring.
• Flera point-in-time snapshots möjliggör för administratörer att återställa till ett tidigare snapshot och därigenom skydda mot logiska fel i applikationen som har eventuellt också har replikerats
• Stöd för Storage DRS – gör det möjligt för replikerade VMs att flyttas via storage vMotion till ett nytt datastore utan påverkan av pågående replikering
• Enklare Managering – Djupare integration med vSphere Web Client för konfigureation och övervakning av replikering i VM- och vCenter managementfönstren förenklar upplevelsen vid managering och replikering
• VSAN stöd för skydd och återställning av virtuella maskiner som körs på ett Virtual SAN datastore

vCloud Suite

Uppdateringarna inom vCloud Director 5.5 releasen fokuserar bland annat på Content Catalog, vApp provisioning och lifecycle management, förbättrad OVF import/export och stöd för fler browsers vilket nu också omfattar stöd för Mac OS.

Site Recovery Manager (SRM)

Några uppdateringar för Site Recovery Manager:
• Support för vSAN med vSphere Replication
• SDRS / Storage vMotion stöd
• Nytt konfigurationsval för support för vSphere Replication Multi-Point-In-Time snapshots vid failover

NSX

En av de riktigt stora nyheterna var NSX, resultatet av uppköpet av Nicira. En produkt som gör för nätverk vad ESX gjorde för servrar, virtualisering av nätverket. Detta kommer utan tvekan att förändra sättet vi ser på nätverk och hur vi använder och kanske framförallt hur vi konfigurerar det. Vi behöver inte längre ha långsamma processer för att sätta upp nya nätverk, vi gör det automatiserat!

Några av de funktioner som omfattas i NSX:
• Logical Switching – Reproduce the complete L2 and L3 switching functionality in a virtual environment, decoupled from underlying hardware
• NSX Gateway – L2 gateway for seamless connection to physical workloads and legacy VLANs
• Logical Routing – Routing between logical switches, providing dynamic routing within different virtual networks.
• Logical Firewall – Distributed firewall, kernel enabled line rate performance, virtualization and identity aware, with activity monitoring
• Logical Load Balancer – Full featured load balancer with SSL termination.
• Logical VPN – Site-to-Site & Remote Access VPN in software
• NSX API – RESTful API for integration into any cloud management platform

Har du tid?

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