(Re)claim your space!

In one of my previous posts, Is Bitlooker from Veeam a game-changer?, I wrote about the benefits of using Bitlooker for backup jobs when using Veeam Backup & Replication v9.x however Bitlooker is a feature that is not only available for backup jobs – you can use it for replication jobs as well.

So I thought it’d be fun to see what difference, if any, it makes. The goal of my tests is to figure out the most effective way of copying/replicating a VM from one host to another.

The set up for the test:

A virtual machine is installed with Windows Server 2016 standard edition. 100 GB disk assigned to the VM, thin provisioned. The disk is then filled with files (a bunch of iso-files of different sizes). That’s the baseline, then roughly 85 GB will be deleted (all the added iso-files) – then trashcan will be emptied. So we’ll have some blocks containing stale/old data, the blocks are marked as available to be reused from the operating system point of view but they haven’t been zeroed out so from any hypervisor (outside the VM) it just looks as any other block containing data.

Operating system installed (Windows Server 2016) and updated. The VM now consumes 13,5 GB worth of storage.

Then a bunch of files were added (almost) filling the entire disk.

From the vSphere side of it:

At this point the just added files were removed and trashcan emptied.

And from vSphere:

Now the command ‘ls’ will not show the actual size, so ‘du’ can be used instead to see the actual size of the vmdk file:

I’m going to test 4 different scenarios:

  1.  Migrate the VM from one host to another offline (VM will be shutdown).
  2. Replicating the virtual machine with VMware vSphere Replication 6.5.
  3. Replicating the virtual machine with Veeam Backup & Replication without Bitlooker enabled.
  4. Replicating the virtual machine with Veeam Bitlooker enabled.

The thesis, or point to prove, is that test 1-3 will have no or little impact on the size of the vmdk file however – magic will happen on test 4. So lets perform the tests and find out for real!

Test 1:

VM moved to another host while offline and now let’s explore what can be seen using different methods.

Inside the VM:

From the host:

So no change in vmdk file size as expected.

Test 2:

The virtual machine will be replicated to another host using VMware vSphere Replication 6.5.

VMware vSphere has been configured using the following settings:

Not alot of settings, in fact, the above settings will have no impact on the vmdk size. They will only have control how the snapshot on the VM will be generated (crash consistent vs consistent backup) and the impact the replication job will have on the network.

Inside the VM:

From the host:

Since ‘ls’ doesn’t show the actual size on a thin disk, disk usage ‘du’ is used instead:

So no change in vmdk file size as expected.

Test 3:

The virtual machine is replicated to another host using Veeam Backup & Replication v9.5.

Replication from a Veeam perspective has been set up, to make a fair comparison to the VMware replication test (test 2), the Veeam job will not use exclude swap file blocks:

Processed and read data in the picture below tells us that Veeam doesn’t know the difference between blocks in use and blocks marked as deleted (the same applies for almost all backup vendors):

Inside the VM:

From the host:

And using ‘du’:

So no change in vmdk file size as expected.

 

Test 4:

Know time for the fun stuff. The virtual machine will be replicated to another host using Veeam Backup & Replication v9.5. We will use both space saving techniques we can enable on the job (with application-aware processing we can also exclude specific files, folders, file extensions but we’re not using that feature in this test)

Now, this is the magic we were looking for! The  proxy server has processed all of the data but it has only read data that contain used blocks!

From the VM:

From the host:

Now the vSphere web client combine the .vmdk and -flat.vmdk file into one (like it’s done forever):

And the disk usage utility shows:

Yikes! That’s cool stuff!

Conclusion:

Bitlooker is a feature you should have enabled on any relevant job. It certainly can be used to reclaim that precious storage space you so desperately need.  Heck, why no use it as part of your normal failover testing, cause you’ll already doing that right? Once a month (or how often you feel appropriate) do a planned failover using Veeam Backup & Replication, verify that you DR plan works and as an added bonus you reclaim disk space in the process!

And yet another benefit is the spent replicating the virtual machine, without Bitlooker it took 30 minutes to replicate the VM from one host to another but it was just shy of 7 minutes with Bitlooker enabled.

So seriously, why are you not using this magic thing? There’s only one drawback, Bitlooker supports only NTFS file system (=Windows VMs).

vSphere Data Protection

VMware has for a pretty long time integrated (at least license wise) a backup engine with vSphere. It’s available as a stand alone OVA download but once deployed it integrates with the vSphere web client. The current release, version 6.1.3, was brought online on the 15:th of November 2016.

The new release of VMware Data Protection, VDP for short, supports VMware ESXi 5.1 or later, vSAN 5.5 or later.

Since it’s been a while since I last had my hands on VDP,  I thought it be a good idea to see how the product has evolved. How to install, configure, backup and so on.

Full disclosure: Amongst others, I’m a Veeam Certified Trainer but I’ll try my best not to be too biased.

Installation is straight forward, get the VDP OVA from VMware bundled with vSphere and deploy the appliance to a host in your environment. I had some issues with my small home lab, DNS needs to be set up and configured correctly with both forward and reverse lookups. Since I don’t have DNS in my lab I was not able to get passed the initial configuration wizard in the VDP, merely altering the hosts file was not enough. But as usual, whenever I need to google a problem I always wind up on William Lam’s webpage – Thanks William! (note to self: Set the web browser start page to virtuallyghetto.com and save valuable time).

VMware has some best practices when deploying VDP:

    • For a better performance of vSphere Data Protection in a high-scaled environment, where Data Domain is the destination or the target, use the following reference to deploy the number of virtual machines according to the capacity of vSphere Data Protection appliance:
vSphere Data Protection Appliance Capacity Number of Virtual Machines to Deploy
0.5 TB 20
1 TB 30
2 TB 40
4 TB 80
8 TB 100
  • For effective load balancing, deploy a maximum of 10 vSphere Data Protection appliances with 100 virtual machines per vSphere Data Protection appliance, in a single vCenter Server domain.
  • In a large environment, deploy a maximum of 8 proxies per vSphere Data Protection appliance regardless the size of the vSphere Data Protection appliances.
  • For better performance of backups and restores, limit the size of each virtual machine to a maximum of 2 TB.

Installing and configuring the VDP:

Once deployed and configured management of jobs are done using the vSphere web client, first thing to do is to connect to the VDP from the web client:

When connected you have a few options, creating a new backup job, verifying a backup job or restoring a backup. You can also download ”Application Backup clients” which can be useful when managing VMs running SQL, Exchange or Sharepoint. The purpose of the agents are to get application consistent backup of VM and have the logs being truncated afterwards.

When you click on the Application Backup clients you end up on the configuration page of the VDP, at the bottom there are links to the individual clients. And on this page you can configure email settings or check log files as well if needed.

Creating a backup job is pretty easy, go through the wizard a change settings, select either ”Guest images” or ”Applications”. If you select Applications you can select what application and specific database you need to back up.

Select what to backup, entire VM or individual disks.

Now you select which VMs to backup, either select individual VMs or a parent container such as a resource pool or a host (or indeed the entire vCenter server). This is where I find myself questioning VMware’s approach a bit. Why can’t you use folders or tags? Grouping VMs in resource pools just for the sake of backup is a bad thing, resource pools are for dividing up resources and should never be used as a ”backup grouping mechanism”. No Tags, folders and so on? Really VMware? Eat your own dog food.

Next you set up the schedule for the backup, you can only set up one backup/restore point per day at most. So you can’t really have advanced scheduling, is backing up a VM once a day good enough? If so then it’s not a problem.

Next, select how long you’d like to keep the restore point. You can either select a simple set up where you set how many days you store the backup or to a specific date but you also have the option of creating a GFS set up. A Grandfather, Father, Son backup is used if you’d like to save weekly, monthly or yearly backups. Nice!

Give the backup job a meaningful name.

Verify that everything is ok.

There you have it, quick and easy to set up. The GUI shows all your available backup jobs on the specific VDP.

Once the backup has been performed you might want to verify that the backup is actually useful, that it can be restored if need be.

Create a new backup verification job.

Select the virtual machines you want to verify.

A heartbeat test will be performed, i.e. the virtual machine will be powered on and VMware will verify that it has a heartbeat to the host (meaning that the operating system of the virtual machine actually started and that the VMware tools service started as well, which will indicated that we have a running OS). But if you provide a script of your own, and have it placed inside the VM you can basically test anything you want. You can perform a much more comprehensive and advanced test for your VMs with a script.

Select a host where you’d like to restore and power on the VM, make sure it has enough resources to actually perform the verification test.

Select the datastore to be used when restoring the VM. Again, the host has to have enough CPU and RAM available to power on the VM but more importantly it has to have enough diskspace as well. Since we have to restore the entire VM the host would need to have free disk space on a datastore. Might not be a problem if we’re verifying a small VM but what about your fileserver or that huge mail server? Do you have X TB available to actually be able to perform the test?

Set a schedule for the verification job, once a week perhaps?

And we give the job a meaningful name.

Verify that everything is ok.

Now we have a summary of all verification jobs available on this VDP server.

It’s possible to either schedule a verification job or to run it manually.

Files of the virtual machine will be restored to the designated datastore and to a folder named VDP_VERIFICATION_<vm-name> -<unique number>.

And there you have it, a successful backup verification performed. Now I have the confidence to restore this particular VM if it would break down for any reason.

 

Replication:

If you are serious about your backup data you would probably want to design the backup environment in a way that it is protected from a complete site failure. That’s not a problem in VDP, there’s a built in function to replicate your backup information making it easy to have a secondary copy of your data on a remote site.

Backups created with VDP 6.0 or later can be replicated to another VDP appliance, to an EMC Avamar server, or to a Data Domain system.

Emergency!

If you need to restore virtual machines, vCenter and VDP needs to be available however there is a way to restore directly to a host if needed. If for instance you need to restore vCenter itself. The processes is called ”Emergency restore” and entails disassociating the VDP from vCenter prior to restoring.

File level restore:

File level restore is possible using the ”VDP Restore Client”, no need for an image based backup and a separate file level backup. The VDP Restore Client is accessed using a web browser from the VM to which you want to restore a file. So it has to be running, no redirected restores unless you’re using ”Advanced login” then it’s possible to mount any backup file and restore it to the current VM you are running the VDP Restore Client on. And since you have to connect using a web browser to the VDP server from the VM, you’re required to have network connection (and any potential firewall ports opened up for traffic). VMware VIX anyone?

The Good:

  • It’s available on almost all vSphere editions (only missing in the smallest, vSphere Essentials kit).
  • Easy to set up, easy to configure.
  • Verify the backup, always a good thing.
  • You can create GFS retention policies.
  • Since you can replicate backups/VMs to a secondary VDP appliance you can protect your workload from a complete site failure, nice!
  • Makes use of CBT to minimizes the impact of the backup.
  • It has some  basic backup functionality which would go a long way for some environments.

The Bad:

  • The VDP appliance version 6.1 does not support backups and restores of virtual machines on Virtual Volumes (VVOLs).
  • An emergency restore operation restores a VM directly to the host that is running the VDP appliance. And the host running VDP can’t be part of the vCenter inventory, if it does – the host also has to be disassociated with vCenter prior to the emergency restore.
  • The Restore Client service is only available to virtual machines that have backups that are managed by VDP. This requires you to be logged in, either through the vCenter console or some other remote connection, to one of the virtual machines backed up by VDP.
  • If you need advanced scheduling of backups, multiple backups a day of a VM.

Summary:

If I try to summarize, VDP has it’s merits. It’s not the full blown availability solution that for instance Veeam represents but then again VDP is free of charge for all licenses of vSphere (it’s available for vSphere Essentials + and upwards) and is not intended to be used for larger organizations I imagine. It’s very easy to set up and if you don’t have any advanced requirements on your backup it should fill your needs. You do need to be aware of and plan for things like resource consumption for backup verification and how to handle file level restores. And it’s a bit disappointing to find a blog post from 2013 talking about tags and folders as ”containers” when creating backup jobs, but nothing has happened yet. It would make a huge difference in terms of management of your jobs.

So, for some organizations, it will be just what the doctor ordered but for others it may be….well, to basic.

Vad är nytt i vSphere 6.0 beta?

VMware har nu annonserat vad den nya versionen av vSphere kommer att innehålla. Här nedan är några av de funktioner som har fått förbättringar och även helt nya funktioner. Listan är på inget sätt komplett utan ett litet smakprov, man kan se att man lagt mycket energi i releasen på att skala upp produkten för ännu större laster men även att automatisering med hjälp av policies är viktigt för VMware. Självklart vill man även se till att hjälpa kunder att göra det enkelt att managera sina virtuella maskiner oavsett om det rör sig om VMs i det egna datacentret eller i VMwares vCloud Air. Och eftersom det är en beta finns det alltid en chans/risk att saker och ting ändras till den officiella releasen.

Compute

  • Utökad support för ny hårdvara, arkitekturer och Gäst OS
    Utökad support för de senaste x86 chipseten, devices och drivers. Ger valmöjlighet hur man bygger sitt moln genom ökad support för OpenStack. Support för FreeBSD 10.0 och Asianux 4 SP3 gästoperativsystem.
  • Ökad skalbarhet
    Configuration maximums hör ökats: Virtuella maskiner stödjer nu upp till 128 vCPUs och 4 TB RAM och hostarna stödjer upp till 480 pCPUs, 12 TB RAM, 64 TB datastores, 1000 VMs och 32 serieportar. Utökat stöd för virtual graphics.

Storage

  • Storage IO Controls
    Support för per virtuell maskin storagereservations för att garantera service nivåer.
  • Virtual Volumes (VVols)
    Befintliga SAN/NAS system blir VM-aware och gör VMDK-filer till ”first class citizens” i storagevärlden. Nya API:er för data operations för VMDK-filer
  • Ökad Storage- och Availability-integration
    Integration med Content Library, storageprodukter och -funktioner inklusive Virtual Storage Area Network (Virtual SAN), Virtual Volumes (VVol), vFlash, vSphere Replication och SRM för förättrad storage och availability hantering.
  • NFSv4.1 med Kerberos
    Support för industristandarden NFSv4.1 i storagestacken. ESX kommer att stödja NFSv4.1 även som klient för anslutning till en NFSv4.1 server. Kerberos kommer också stödjas då detta är en säkerhetsfunktion i NFSv4.1.

Availability

  •  vMotion förbättringar
    • vMotion mellan vCenter Servrar – Gör det möjligt att flytta VMs mellan vCenter Servrar och Datacenter- och Folders-objekt.
    • vMotion mellan virtuella switchar – Gör det möjligt att flytta VMs mellan virtuella switchar.
    • Long distance vMotion – Gör vMotion över avstånd med mer än 100ms round-trip time.
  • vSphere Fault Tolerance för multi-processor VMs (SMP-FT)
    Fault Tolerance har nu möjlighet att skydda virtuella maskiner med upp till 4 vCPUs.
  • vCloud Hybrid Service (vCHS) integration
    Nya möjligheter att replikera och göra backup till vCHS-molnet.
  • vSphere Replication
    Utökad skalbarhet och performance för vSphere Replication. Förbättrade Recover Point Objectives (RPOs) med ner till 5 minuter. Support för replikering av upp till 2000 VMs per vCenter server.
  • Application High Availability (App HA)
    Support för fler business critical applications.

Network

  • Network IO Control
    Ny support för per virtuell maskin och Distribuerad vSwitch bandbredds reservartioner för att garantera service nivåer.

Management

  • vSphere Web Client förbättringar
    Managering av infrastruktur (via component manager) och förbättringar i tagging-mekanismen.
  • Multi-Site Content Library
    Tillhandahåller enkel och effektiv hantering av VM templates, vApps, ISO-images och skript för vSphere administratören – kollektivt benämt ”content” – som kan synkroniseras mellan siter och vCenter servrar.
  • Virtual Datacenters
    Möjliggör resursaggregering och policy-baserad placeringsintelligens samtidigt som det utgör den primära integrationspunkten genom vCloud Suiten.
  • Policy Based Management
    Gör det möjligt för administratör att bli mer ”operationellt effektiva och automatiserade” både vad gäller initial placering och efterföljande hantering av virtuella maskiner.

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

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.

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

VMware vSphere 5.1 uppdatering släppt

Ä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

VMware vSphere 5.1 licenser

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