Hardware Automation - BIOS settings

 As you know there are several hardware vendors outside and so by nature all use different ways to automate their kit. Luckily something I would call standard has made it the most vendor APIs – Redfish API.

For both parts I like to concentrate on HPE first, as this is one of the major players in the game.


As we are clearly looking with VMware glasses at the whole topic, I will reuse the tools I used to automate customers VMware VVD/Cloud Foundation deployments – vRealize Orchestrator.


In case of HPE there is a tool that they offers, which could solve baselining the just discussed problems, but also might not meet your requirements. I’m speaking about OneView. This tool from HPE clearly focus on HPE hardware and does not provide me a solution, which I can use across a heterogeneous hardware landscape. So it is not an option for me.

What I definitely like to use, are the APIs OneView is leveraging to automate the individual hardware components. One of these is the iLO RESTful API.

It is there since iLO 4 2.00 (found on Gen8 and Gen9 kit) and has enhanced with every new minor release. The latest evolution is iLO 5 with the broadest feature set so far.

I will reduce the scope to iLO 5 only for now, as this covers most current deployments, because it comes with all Gen10 kit HPE delivers to the customers at the moment. In a later article I might show, what I also developed to support iLO 4 on Gen8 and Gen9 hardware.


But kick it off. The iLO Edition you will need to follow my explanations in the content below and as well in the following parts is “Advanced”.


Looking at the BIOS settings it is always a good idea to create a golden host, which contains the BIOS configuration you like to distribute to all other nodes of the same model in your datacenter. I will not provide any guideline on how to find your optimal configuration in this article, but maybe in a future one. For the time in between I like to recommend the “VMware vSphere 6.5 Host Resources Deep Dive” by Frank Denneman and Niels Hagoort.

Assuming you have configured a host according to your needs, we first need to read the current configuration from this node via its iLO RESTful API. Clean it up and make it our golden configuration to use for every deployment of a new new server or distributing it across your existing estate.


As we need to run all iLO tasks in the same way, I have created a wrapper workflow, which takes the individual request and handles authentication for us.

var auth = RESTAuthenticationManager.createAuthentication("Basic",["Shared Session",user,password]);

var host = RESTHostManager.createHost(name);
host.url = url;
host.connectionTimeout = connectionTimeout;
host.operationTimeout = operationTimeout;
host.hostVerification = hostVerification;
host.authentication = auth;
// create temporary host
var restHost = RESTHostManager.createTransientHostFrom(host);
// prepare and execute main rest request
var request = restHost.createRequest(callmethod,call,callcontent);

if(callmethod != "GET")
  request.contentType = "application/json";
var response = request.execute();
if(response.statusCode != "200" && response.statusCode != "201")
  System.debug("Status code was "+response.statusCode);
  throw("return code of main request was not 200 or 201");
responseStatusCode = response.statusCode;
responseContent = response.contentAsString;


Read configuration

The following call is just passed through the wrapper workflow as GET request:


Read iLO BIOS config

Read iLO BIOS config

Clean up

As you might have seen while looking at the JSON output of the read call that the response contains a lot of personalized information of the server, like server name and serial number. This we don’t want to have on the new server, so we just delete the parts in the JSON structure. (The server name might be useful, but need to be individualized for every write action)

  "Attributes": {
    "AcpiHpet": "Enabled",
    "AcpiRootBridgePxm": "Enabled",
    "AcpiSlit": "Enabled",
    "AdjSecPrefetch": "Enabled",
    "AdminEmail": "",
    "AdminName": "",
    "AdminOtherInfo": "",
    "AdminPhone": "",
    "AdvancedMemProtection": "AdvancedEcc",
    "AsrStatus": "Enabled",
    "AsrTimeoutMinutes": "Timeout10",


Write back to a new host

The write process is pretty easy and as quick as the read process. We just need to run a POST request to the same URL containing the amended JSON response from the read call as payload. You can paste this configuration every time as workflow input or, like me, read it from a configuration element. In my case I’ve created a dedicated one, contains an entry for each server mode so I can read it based on the model returned by the API.

You might wonder if this configuration is active already – no. HPE is using an approach many network hardware vendors are using for their configuration. There are two types of configurations, the running configuration, the one that is currently active and the pending configuration (the one you have just changed). In our case the pending configuration automatically gets active once the server is reset.

When the server boots through POST, you will notice that a remote configuration takes place and the server might automatically restarts multiple times – this is the point where your configuration gets active.



Write iLO BIOS config

Write iLO BIOS config


Congrats you successfully distributed your custom configuration. This process might be adapted for other vendors. Stay tuned on updates for at least Dell in my pipeline.

For sure this only covers a single host. Feel free to wrap this into a loop or use this is part of a higher level workflow.


All code can be downloaded as vRO package from here:


(you need to set the iLO password in the Configuration Element section before running the workflows, otherwise they will fail)


Hardware Automation - Motivation

Automation in and around the SDDC mostly focuses on orchestrating virtual infrastructure for certain operational processes or leveraging it to deploy workloads/services as part of bigger blueprints.

From my day to day experience the most overseen part is the key component which enables SDDC in the first place – the underlying hardware.

Your are totally right in saying that hardware should be treated as cattle and not as pets, but mostly it lacks the level of automation exists for the virtual infrastructure in most companies.

API first claims, as done by many software vendors, have not made it the hardware producing companies so far. Many of them just have started on providing public APIs to their components.


So, what key advantages can you expect, if you invest mostly time into automating hardware:


  • Reduce hardware deployment times
  • Profiling customizable settings of your hardware, i.e. BIOS/UEFI Settings to ensure same reliability and performance across your estate, which gives you
  • Less situations of unpredictable behavior (who would have though about different BIOS settings, if you try to find an issue with your hypervisor)
  • Maintain vendor supplied hardware-firmware-driver combinations
  • Ensure that rolled out firmware and configuration settings comply with the standard you have engineered and tested


Looking back the last years many customers were facing issues in there environment because of such configuration drifts I just mentioned above. Standardization is key here. Some of you might argue that automation would make issues available everywhere, not just in single servers. That‘s basically correct, but is in the end a quality problem of your engineering:) Apply the same engineering and testing efforts to your hardware configurations and your will win.

A lot of companies roll the server hardware into their datacenter as they will arrive from the vendor and assume the vendor has chosen the right configuration for them. How the vendor should have known what your intended workload is? But even this methodology does not ensure that the servers are using the same firmware nor BIOS configuration. Trust me.


The following content should give you and idea what options you have to baseline your hardware. The content will be split up in two parts:


Build a hardened ESXi 6.5 image for HPE hardware

As part of the series for ESXi 6.5 this post should give you an idea of how to handle a ESXi image build in detail. No long introduction. Let’s start:


  1. Get you the latest ESXi 6.5 offline bundle available from
    VMware Patch Repository (MyVMware Login required)

  2. Get the required drivers and agents from HPEFirst check the recipe for the right firmware and driver combinations. This maybe requires you to update firmware on your boxes.
    HPE ProLiant server and option firmware and driver support recipe 

    Download the required drivers for the latest folder container esxi-650-* hierachie
    (alternatively you could connect this online, but have to build the image without a proper internet connection)

    The “esxi-650-devicedrivers” folder contains the right offline bundles for the drivers. Pick the ones you need for your hardware. If you have no idea how to find our what driver is required, please play around a little bit with the “esxcfg-*” commands on the ESXi Shell. List your network and storage adapters on an existing ESXi, best installed with vendor image, and note down the drivers are used.

    The “esxi-650-bundles” contains all additional agents and tooling. Just download the hpe-esxi6.5uX-bundle-* file as this does contain the  hpe-smx-provider CIM provider integration you need for proper hardware monitoring.Some of the drivers are double zipped. Just extract the first layer so you have the offline bundle. The second zip file should not contain any further *.zip file, but *.vib or a vib20 folder.

  3. Setup a PowerCLI 6.5 environment on a compatible Windows machine


  1. Load the VMware ESXi vanilla image
    Add-EsxSoftwareDepot .\ESXi650-201703002.zip
  2. Clone it for further modification
    PS> Get-EsxImageProfile | Select Name
    Select the standard image. For other patch offline depots you might see for Image Profiles. Pick the standard one without “s” behind the number.
    New-EsxImageProfile -CloneProfile ESXi-6.5.0-20170304101-standard -Name "ESXi-650-custom-hpe-hardened"  -Vendor "schoen computing"
    The Acceptance Level gets automatically inherited from the source image. You don’t need to explicitly specify the parameter.

  3. Remove packages
    Remove-EsxSoftwarePackage -ImageProfile ESXi-650-custom-hpe-hardened -SoftwarePackage xhci-xhci
    I removed these packages for my use case:
    This list does also contain drivers now get removed, but later added from the HPE depot in a newer version.

    Attention: Not all packages can be removed in the listed order as there dependencies between them. If the CLI does not allow you to remove a package as it is a required for another package, just remove the other first and try again.

  4. Export the stripped image
    Export-EsxImageProfile -ImageProfile ESXi-650-custom-hpe-hardened -ExportToBundle -FilePath .\ESXi-650-custom-hpe-hardened.zip
    This image now does contain only the left packages. I prefer now to close the PowerCLI session and load the exported image in a new session like in step 1.

  5. Add HPE offline depots
    Add-EsxSoftwareDepot .\<hpe driver/bundle>.zip
    Add all downloaded and extracted zips in the way above.

  6. Add the HPE packages to the image
    Add-EsxSoftwarePackage -ImageProfile ESXi-650-custom-hpe-hardened -SoftwarePackage <package name>
    The package names can be get from the offline depot zip files. These contain a folder for each package name in  vib20  folder. For my use case these packages were added:
  7. Export the finale image
    Export-EsxImageProfile -ImageProfile ESXi-650-custom-hpe-hardened -ExportToBundle -FilePath .\ESXi-650-custom-hpe-hardened.zip
    Export-EsxImageProfile -ImageProfile ESXi-650-custom-hpe-hardened -ExportToIso -FilePath .\ESXi-650-custom-hpe-hardened.iso

     Keep the ZIP store anywhere as you can use it for updating and extending the image.

ESXi 6.5 security/hardening

ESXi Hardening – loved and hated. What do have already in this space? VMware provides a hardening guide for all the latest versions of ESXi. Looks like with 6.5 there was a change in naming: “Security Configuration Guide“.  I think is pretty much well known, but in my day-to-day work this is only one part to build a hardened hypervisor. Especially if you work with large and security sensitive customers, you should put more brain work into this topic. As this is a growing topic, best is to set up a series for it:
  1. ESXi image
  2. SSL/TLS
  3. DMZ
  4. Monitoring
Stay tuned!

VMware Validated Designs does not exclude Stretched Cluster in general

Working as an architect in the VMware space you will sooner or later come across the VMware Validated Designs (VVD). Just a few weeks ago the latest version 4.0 was released to make adjustments for vSphere 6.5. It can be found here:

VMware Validate Designs Documentation

The designs are a great source for building your own architectures or building architectures for customers. The incorporated component architectures are natively built for availability, reliability and scalability. These are exactly the main goals I try to put in the designs I create for customers. The VVDs show up a good practise for a detailed setup that can be used for several use cases like Private Cloud or VDI deployments. VMware Cloud Foundation also makes use of the VVDs for its implementations.

But apart from this I also like to treat them as a framework which gives me the chance to keep the setup supported by VMware but also adjust it to the customer needs and make it fit like a second skin based on customers requirements.

Across their history they mainly relied/rely on a two region concept with one primary and fail-over region. This is a quite common architecture for U.S. setups. In the European space and especially in Germany customers often stick their existing architectures based a two datacenters setup working as an active/active pair. If you see this also as a two region setup or you would aggregate this into one region like me, is up to you. I prefer one region because the datacenters are in a short distance because of their synchronous replication/mirroring and so they build up a logical domain because for their active/active style.  This is why I split the region down to two physical availability zones (AWS term) and one virtual across two datacenters. This does not need to be undestand now, it will get clearer in later chapter.

In my understanding the VVD framework needs some extension in regards to Stretched Clusters and this is why I like to set up a series which guides through a forked version of the VVDs I personally use for customer designs:

  1. General thoughts
  2. Additions/Changes to physical architecture
  3. Additions/Changes to virtual architecture
  4. Additions/Changes to cloud management architecture
  5. Additions/Changes to operations management architecture
  6. Additions/Changes to business continuity architecture

Stay tuned!






Set up vCenter HA in advanced mode with different heartbeat networks

Setting up vCenter HA in basic mode is pretty straight forward.

Doing the same in advanced mode is a little bit more tricky. But first, why I need to go with the advanced vCenter HA mode?

  • the VCSA is managed by another vCenter (for example if the setup is according to the VMware Validated Design 3.0)
  • the heartbeat vNICs are not in the same IP subnet

Luckily I to cater with both in a project.

I don’t want to create much content by copying from VMware documentation, so I only like to give some hints and describe some pitfalls you might get into, when setting this up and last but not least describe what VMware missed in there official documentation:


Preparation pitfalls

DNS reverse lookup

Basics, basics, basics. Ensure that you have a proper DNS reverse lookup implemented. Also take care of the exact writing of the host names. Don’t maintain a hostname entry in the DNS system with capital letters and use a non-capital or mixed one in your VCSA. This basically does not work, because the self-lockup fails. The GUI won’t tell you that, but if you run the preparing with prepare-vcha cmd line interface I will show up some more info.


Procedure pitfalls

When have you clicked through the first step in GUI, the next step is to clone the VCSA two times, once for the passive node and second one for the witness node. Very important is, that you don’t clone before the first step has finished. Otherwise the communication between the appliances won’t work because they use the wrong SSH keys. This is also valid, if you try to use the same cloned appliances for setting this up a second time – this won’t work. You need to throw them away and clone new ones at the right point in time.


The official documentation does not describe the customization stuff in much detail. Maybe that is not necessary, but if something is not totally clear to you, here some hints:

Passive node: documentation is clear, but really, you need to configure the first NIC (NIC 0) with the same IP config like the primary vNIC of your original VCSA. The adapter gets automatically shut down while first boot, so there is no IP conflict in your network – or better only for a short moment. NIC 1 set to the heartbeat network info you have prepared. Ensure that you really don’t set a gateway on this adapter.

Witness node: the documentation stated here to also leave the gateway out for the required heartbeat NIC. I have not done this, as I set the first adapter unused or shut it down. The second one I set to the heartbeat IP and used also a gateway. The gotcha was, that the witness had an IP in a totally different subnet than the active and the passive VCSAs. Static routes might also do the job, but I had some trouble with that.

First start

Start up the appliances. The IP conflict resolves as described above. Before to click the next step in the GUI, ensure that you do the following:

Go to both active and passive VCSA and add a static route so they can reach the witness via the heartbeat interface:

Edit /etc/systemd/network/10-eth1.network and add the following lines at the end:


The destination can be limited to the heartbeat IP of the witness VM. The gateway must be the gateway of the IP subnet used for the heartbeat in the local VCSA appliance. Repeat this on the passive appliance (best is to SSH to it via the active one).

Now and only now hit “Finish” in the GUI and all should go well. You can check the log /var/log/vmware/vcha/vcha.log for further info.

vSphere Replication mit eigenen Zertifikaten

Der Einsatz von vertrauenswürdigen Zertifikaten für die Absicherung von internen Diensten wird in vielen Unternehmen stark vernachlässigt. Viele Unternehmen setzen sie ausschließlich für extern gehostete Dienste bzw. Dienste, die über die hauseigene DMZ bereitstellt werden, ein. Fragt man nach den Gründen, warum intern genutzte Dienste vernachlässigt werden, wird oft der Aufwand der Implementation und die fehlende Certificate Authority (CA)-Infrastruktur angeführt. Nahezu alle Unternehmen nutzen das Microsoft Active Directory (AD) zur Bereitstellung von Verzeichnisdiensten. Viele wissen jedoch nicht, dass dies die ideale Methode zur Verbreitung von unternehmensweiten Zertifikaten ist. Am Anfang steht jedoch der Aufbau einer internen CA, da die Unternehmen zumeist eigene DNS-Namensräume (Domänen) verwenden bzw. die Kosten alle internen Client/Server mit einem Zertifikat zu versorgen, unterverhältnismäßig sind. Microsoft bietet im Lieferumfang des Windows Server 2008 R2 eine Rolle an mit der sich eine CA betreiben lässt, was somit für fast alle Unternehmen kostenfrei ist. Über das AD kann dann das erstellte Root-CA-Zeritifkat bzw. auch die erstellten Intermediate-CA-Zertifikate an die Client-Truststores ausgerollt werden. Somit sind alle von der Root- oder Intermediate-CA ausgestellten Zertifikate innerhalb des Unternehmens-AD vertrauenswürdig. Für spezielle Dienste wie z. B. das VMware vCenter können dann zusätzlich zu den dann bereits vorhandenen Client-Zertifikat weitere Server-Zertifikate bei der CA beantragt werden. Dies garantiert eine gesicherte Kommunikation auch innerhalb des Unternehmens. Für Server, unabhängig ob physikalisch oder virtuell, die mit Unix/Linux-Derivaten betrieben werden ist ein manueller Import der CA-Zertifikate nötig. So auch bei den Appliances von VMware. Im Fall der vSphere Replication Appliance wird das Root-CA-Zertifikat und ein eventuell vorhandenes Intermediate-CA-Zeritifkat einerseits in den Java-Truststore der Anwendung als auch in den Linux-System-Truststore importiert. Zusätzlich machen wir beide CA-Zertifikate auch dem Webserver für die Managementoberfläche bekannt. 1. Vorbereitungen a) Root-CA-Zertifikat (bspw. “root.crt”) und Intermediate-CA-Zertifikat (bspw. “intermediate.crt”) per SCP auf die vSphere Replication Appliance kopieren b) aus beiden Zertifikaten wird nun eine Zertifikatskette (Chain) erzeugt: 2. Zertifikat in den Java-Truststore von vSphere Replication importieren: 3. Zertifikat in den Linux-Truststore importieren: 4. Zertifikat dem Webserver der Managementoberfläche bekannt machen: Im Anschluss kann das vorbereitete Server-Zertifikat im PFX-Format über die Managementoberfläche https://myreplicationappliance:5480/ > Configuration eingespielt werden.

Erneute Probleme mit SSO in vCenter 5.1 U1a

Auch mit vCenter 5.1 U1a kann es erneut zu Probleme mit der SSO-Komponente kommen. Diese scheinen im Gegensatz zu den vorherigen Versionen anders gelagert zu sein. Bei Tests ergab ich ein Problem mit Benutzern, die in einer Active Directory Group sind, die wiederum zu den lokalen Administratoren hinzugefügt wurde. Wurde nun bei der Installation des vCenter’s die lokale Administratorengruppe mit der Rolle “Administrator” auf das Inventory-Root (vCenter Objekt) berechtigt, kann dies dazu führen, dass der Benutzer der AD-Gruppe die Meldung bekommt, der er keine Rechte auf die nötigen Objekte hat. Der Web Client ermöglicht zwar einen Login, jedoch sind keine vSphere Ressourcen aufgrund ebenfalls fehlender Rechte sichtbar. Einigen Nutzern der AD-Gruppe kann ein Login trotzdem möglich sein, wenn diese schon über eine andere AD-Gruppe zu den lokalen Administratoren hinzugefügt wurden. Es gibt zwei Möglichkeiten um dieses Problem zu umgehen, da es bisher noch keinen Patch seitens VMware gibt:
  1. Es wird eine zweite lokale Gruppe hinzugefügt und die AD-Gruppe dort als Mitglied aufgenommen. Achtung: Die zweite lokale Gruppe muss danach noch gesondert auf das Inventory berechtigt werden.
  2. Es wird eine SSO-Gruppe angelegt und die AD-Gruppe als Mitglied aufgenommen. Achtung: Die SSO-Gruppe muss danach noch gesondert auf das Inventory berechtigt werden.
Beide Workarounds setzen voraus, dass noch Zugriff aus das vCenter Inventory besteht. Alternativ sollte man bei der Installation stattdessen einen Service-AD-Account berechtigen oder direkt eine AD-Gruppe. Beide Methoden umgehen ebenfalls das Problem. Die Problem werden ebenfalls von Magnus Andersson hier beschrieben: http://vcdx56.com/2013/06/24/vcenter-server-and-vcenter-single-sign-on-authentication-problem/

vCenter Hochverfügbarkeit mit vSphere Replication

Das Management ist in IT-Infrastrukturen oft das schwächste Glied in der Umgebung und wird in vielen Desaster-Plänen nicht beachtet. Fällt in einer vSphere-Infrastruktur beispielsweise das vCenter aus, können wichtige Funktionen, welche zum Betrieb und Management der Infrastruktur notwendig sind, nicht mehr ausgeführt werden.  Hierzu zählt z.b. Dynamic Resource Scheduling (DRS), vMotion oder auch Storage vMotion. Genauso ist der Zugriff auf die Distributed Switche eingeschränkt. Unter anderen aus diesen Gründen besteht bei Kunden immer wieder die Notwendigkeit, Lösungsszenarien dazustellen,  welche die wichtigen Management Komponenten hochverfügbar machen. Wo liegt das Problem? Grundlegend gibt es vier Fehlerszenarien, die den Betrieb des vCenter unterbrechen können. Dabei wird jeweils der Betrieb des Applikationsservers mit allen vCenter-Komponenten (vCenter Server, Inventory Service, Orchestrator, SSO, Update Manager) sowie einer externen MSSQL-Datenbank angenommen. Alle Szenarien lassen sich aber ebenso für verteilte vCenter-Komponenten, sprich verteilt auf verschiedenen Server, anwenden. Folgende Ausfallszenarien können eintreten:
  1. Probleme auf Betriebssystem- und Software-Komponentenebene (Update)
  2. Ausfall oder Störung eines Blades im Enclosure
  3. Ausfall oder Störung des gesamten Enclosures
  4. Ausfall oder Störung des gesamten Datacenters
Szenario Eins kann beispielsweise beim Einspielen von Windows Patches und dem Update von vCenter-Komponenten auf einen neuen Release-Stand eintreten. Hiergegen sollte man sich vor einem Updat,e mit Backups der Datenbanken (SQL und ADAM) sowie einem zusätzlichen Snapshot der VM’s, vor dem Update absichern. Szenario Zwei skizziert den Wegfall des ESXi-Host, der im dem Moment des Ausfalls die vCenter-VM(s) oder die Datenbank bzw. mehrere vCenter Komponenten ausführt. Um die Komponenten in diesen Fall möglichst schnell wieder in den normalen Betrieb zu nehmen, sollte man auf ein, bei der Inbetriebnahme des Clusters aktiviertes, vSphere HA setzen. Dieser startet nach dem Ausfall die VM’s des ESXi-Hosts auf anderen Hosts im Cluster neu solange die nötigen Ressourcen hierfür vorhanden sind. Für Szenario Drei muss bei Blade-Umgebungen auf das vorliegende Cluster-Design geachtet werden. Bestmöglichst, erstreckt sich ein vSphere Cluster über mindestens zwei Blade-Enclosures. Weiterhin ist darauf zu achten, das die nicht ausgefallenen Enclosures genug Failover-Kapazität (Admission Control) bereit halten. So lassen sich die ausgefallenen VM’s, wie in Szenario 2, dort neustarten und so eine möglichst geringe Ausfallzeit garantieren. Vorsicht ist geboten, wenn alle vSphere Hosts (Blades) im Cluster in nur einen Enclosure sind. In diesen Fall muss über eine andere Lösung zur schnellen Wiederaufnahme des Betriebs gesetzt werden, da vSphere HA in dieser Situation nicht greift. Erschwerend kann hinzukommen, dass die Datastores/LUN’s auf denen die entsprechenden VM’s liegen, lediglich den ESXi-Hosts dieses Clusters präsentiert werden (z. B. Fibre Channel Zoning). Für dieses Szenario muss also eine Replikation der Daten auf ESXi-Host-Ebene (Block-based; Host based Replication) oder auf Applikationsebene erfolgen. Für beide Szenarien bietet VMware jeweils ein Produkt an. Für beide Ansätze wird kein zusätzliche Array-basierte Replikation (z.B. EMC SRDF) benötigt. Eine Lösung ist VMware vCenter Server Heartbeat. VMware vCenter Server Heartbeat arbeitet auf Applikationsebene und spiegelt die Dienste auf eine “Failover”-VM. Im Falle des Ausfalls der primären Seite, kann die Failover-Seite nahezu unterbrechungsfrei den Betrieb aufnehmen. Eine kostengünstigere Alternative mit einer etwas höheren Wiederherstellungszeit und manuellen Eingriff bietet die Lösung “vSphere Replication”. Diese ist bereits in allen vSphere-Paketen ab der “Essentials Plus”-Variante mit Lizenziert. Weitere Details zu dieser Lösung finden sich im zweiten Abschnitt. Szenario vier, bspw. verursacht durch einen Stromausfall im gesamten Datacenter, stellt eine Situation dar, in der zumeist der Betrieb des vCenter’s obsolet ist, da alle verwalteten Ressourcen auch ausgefallen sind. vSphere Replication Eine Replikation mit vSphere Replication unterscheidet sich gegenüber vCenter Server Heartbeat (nachfolgend Heartbeat genannt) grundlegend in zwei Merkmalen. Es findet entgegen Heartbeat eine Replikation von Speicherblöcken auf vSphere Hypervisor-Ebene statt und zusätzlich ist die Replikation nicht synchron. Im Unterschied zu Heartbeat kann diese Replikation aber für alle VM’s angewendet werden, da sie für das Betriebssystem transparent ist. VMware Heartbeat beschränkt zusätzlich nur auf Windows-Systeme. vSphere Replication erlaubt eine periodische Replikation der geänderten Speicherblöcke einer VM in einem Abstand von 15 min bis zu 24 h, der sogenannten RPO (Recovery Point Objective). Dabei werden am Ende der Periodendauer mittels CBT (Changed Block Tracking) alle geänderten Blöcke aus dem CBT-Log auf eine “Failover”-Seite übertragen. Diese Mthode entlastet die Replikationsstrecke und ermöglicht kürzere Replikations-Zyklen. Voraussetzung für die Replikation der vCenter-Komponenten sind zwei vCenter-Instanzen, die sich später idealerweise über Kreuz replizierten. Zusätzlich wird für beide vCenter-Instanzen jeweils eine vSphere Replication Appliance benötigt, die an das vCenter als vService gebunden wird. Beide vCenter müssen vSphere-Ressourcen verwalten, die später als Quelle und Ziel für die Replikationen dienen. Dabei werden die Blöcke einer VM vom ESXi-Host auf dem die VM ausgeführt zur vSphere Replication-Appliance des zweiten vCenters repliziert, die wiederum die Blöcke über einen ESXi-Host auf den gewählten Datastore der anderen Seite herunterschreibt. Nachfolgende Grafik soll dies verdeutlichen: vSphere Replication architecture Der Hauptgrund für das Vorhandensein einer zweiten vCenter-Instanz ist der Recovery-Prozess. Für die Inbetriebnahme der ausgefallenen VM’s ist das vSphere Replication-Plugin im Webclient nötig. Ist dies gegeben, lässt sich relativ einfach über den Webclient der Betrieb der VM’s wieder aufnehmen. Nutzt man man nur ein vCenter und eine vSphere Replication-Appliance kann man zwar die VM’s auf andere Datastores und Cluster replizieren, jedoch hat man das Henne-Ei-Problem, der Dienste die zum Wiederherstellen der VM’s gebraucht werden. Man sollte nicht unerwähnt lassen, dass solange die VM-Dateien (VMX, VMDK) vorhanden sind sich der Betrieb auch wieder per Hand aufnehmen lässt. Nur ist diese Möglichkeit wesentlich komplizierter und erfordert eine gut dokumentierte Anleitung. vSphere Replication ist nicht auf Szenario drei begrenzt. Es eignet sich auch für Szenario eins. Hier kann die Replikation, der zu aktualisierenden VM’s auch pausiert werden, sodass etwaige Fehler nicht in das Replikat übertragen werden. In diesem Falle kann ein einfach Rollback über die Recovery-Funktion des vSphere Replication gemacht werden. Dies stellt eine weitere Alternative zu Snapshots dar. Die Einrichtung sowie die spätere Konfiguration erfolgt ausschließlich über den vSphere Webclient. Über das Plugin, im vCenter “1”, lässt sich das gegenüberliegende “vCenter 2” als zweite “Site” hinzufügen und umgekehrt. Die Konfiguration der Replikation auf VM-Basis erfolgt über das Kontextmenü in der gewohnten Inventory-Sicht. Besonders zu erwähnen ist im Falle von SQL-Datenbankservern die VSS-Funktionalität. Mit dieser lassen sich die Datenbanken zum Zeitpunkt der Replikation in einen konsistenten Zustand versetzten. Der Status und die initiale Synchronisation der eingerichtete Replikation kann dann wieder über das vSphere Replication-Plugin im Webclient begutachtet werden. Nachfolgende Videos sollen die Installation und Konfiguration der Umgebung verdeutlichen. Diese Lösung wurde durch VMware validiert und wird nach der Veröffentlichung eines Whitepapers/KB-Artikel als “supported” gekennzeichnet werden.

Login Passthrough vSphere Web Client 5.1

Durch die Anbindung des vCenter’s an das firmeninterne Active Directory bietet der vSphere Client sowie der vSphere Web Client die Möglichkeit durch setzen der Checkbox “Windows-Sitzungsanmeldedaten verwenden” ein Passthrough der Windows-Anmeldung zur SSO-Komponente zu nutzen. Mit der Version 5.1 bzw. 5.1 U1(a) kann es nun passieren, dass diese Variante der Anmeldung im Web Client nicht mehr funktioniert. Ursache dafür können unzureichende Rechte für das Starten des RSA SSPI-Service  durch den Network Service sein. Um dies zu prüfen, reicht es festzustellen ob im Task-Manager unter Prozesse der Eintrag “sspiservice.exe” aufgeführt wird. Ist dies nicht der Fall, lässt sich das Problem wie folgt behandeln:
  1. im Windows Explorer in das folgende Verzeichnis wechseln:
  2. in das Eigenschaftsmenü des Ordners “windows-x86_64” wechseln
  3. die Rechte des Ordners für den “Netzwerkdienst” bzw. “Network Service” auf “Lesen und Ausführen” bzw. “Read and Execute” setzen, nur lesend ist nicht ausreichend (ggf. muss der Dienst explizit hinzugefügt werden)
  4. der SSPI-Service muss danach neuinstalliert werden mit folgendem Kommando: der Port kann aus folgenden Datei entnommen werden:
Der SSPI-Service sollte danach automatisch gestartet werden und der Login mittels Passthrough funktionieren.