vCenter DB veraltete IP-Adresseinträge der Hosts löschen

Wednesday, 31 March 2010 16:21:40 (W. Europe Daylight Time, UTC+02:00)
Bei einem meiner Kunden musste ein IP-Adressredesign stattfinden. Dazu mussten natürlich auch die IP-Adressen der ESX-Hosts und des vCenter Systems geändert werden.
Da direkt auch ein Upgrade des vCenter Servers auf die Version 4.0.x an stand hatten wir uns kurzfristig dazu entschieden das vCenter System komplett neu zu installieren auf einer neuen Plattform und nur die Datenbank zu übernehmen. Die ESX Server werden erst in der weiteren Folge auf die Version 4.0.0 aktualisiert, da es keinen funktionalen Grund gab dieses Upgrade zeitgleich umzusetzen. Gesagt getan, alle ESX Server wurden mit den neuen IP-Adressen "versorgt". Für eine Übergangszeit sollten beide IP-Adressbereiche erreichbar / erhalten werden, bis die endgültige Umstellung aller Servernetze abgeschlossen war. Soweit so gut. Alle Funktionen liefen vollkommen fehlerfrei und so sollte es auch während des Mischbetriebes bleiben.
Nachdem der endgültige Cut im Netzbereich vollzogen war liefen die ESX Systeme soweit auch fehlerfrei, allerdings informierte mich der Kunde darüber, dass er weder einen Klon-Prozess starten könne noch aus einem Template eine VM ausrollen konnte, immer mit der Fehlermeldung "failed to connect to host", obwohl der vCenter Agent aus dem vSphere Agent ansteuerbar war.
VMware KB Eintrag dazu: http://kb.vmware.com/kb/1010837

Ursache:

In der VPXDB waren nicht alle ESX Server IP-Adressen umgesetzt worden. Dort standen noch die alten IP-Adressen in der Datenbank!
Das reine ESX-Server aus dem vCenter herausnehmen und wieder hineinbringen brachte auch keine Lösung genauso wenig, wie das manuelle editieren der vpxa.cfg Datei
/etc/opt/vmware/vpxa/vpxa.cfg
, wie in manchen Foren beschrieben, da das vCenter immer Vorrang vor der lokalen Konfiguration hat, wird die falsche Einstellung mit dem Neustart des VPXA Agenten auf dem ESX Server erneut durch die falschen Parameter (IP-Adresse) aus der führenden Datenbank VPXDB ersetzt - per Push-Verfahren.

Lösung:

Die fehlerhaften Informationen finden sich in der SQl Datenbank wieder. Um diese Parameter ändern zu können muss das vCenter herutergefahren, sprich der Dienst beendet werden und die Datenbank darf nicht im Zugriff eines SQL Agenten sein. So dann kann man sich mit dem SQL Server Management Studio auf dem SQL Server anmelden, am besten mit dem VPXDB Benutzer, da dieser alle Berechtigungen für die Datenbank besitzt. Dann muss man die folgende Tabelle einmal aufrufen VPXDB.dbo.VPX_HOST und das folgende SQL Skript pro ESX Server ablaufen lassen:


UPDATE vcdb.dbo.VPX_HOST
SET IP_ADDRESS = ‘192.168.0.11’
WHERE DNS_NAME = ‘esxsrv011.domain.tld’


Im Anschluss kann das vCenter System neu gestartet werden (Dienst oder ganzer Server) und die VPXA Agenten ziehen sich die "richtige" Konfiguration aus der Datenbank. Danach funktionierte dann wieder alles wie gewohnt, klonen, Templates, svMotion etc.

SQL Express Datenbank wächst auf über 4GB an!

Thursday, 25 March 2010 17:05:12 (W. Europe Standard Time, UTC+01:00)
In einem Projekt mit einem vCenter System und nur insgesamt vier ESX Servern hatten wir uns für die kostenfreie Variante des SQL Servers SQL 2008 Express Edition entschieden, da die gesamte zu erwartende Datenbankgröße vom vCenter auf unter 3,0GB angegeben wurde. Leider wuchs die SQL Datenbank schneller als berechnet und erwartet, so dass der vCenter Dienst nicht mehr startbar war und ein Purgen von Tasks und Events über das vCenter System selber nicht mehr möglich war.
Das Dilemma, eine Komprimierung der SQL Datenbank führte zwar zu dem gewünschten Ergebnis (DB < 2GB) aber die Express Variante startet keine komprimierten SQL DBs! Eine Einschränkung, die mir auch neu war. Daher half nur Folgendes:
  1. Neue Windows VM anlegen
  2. Testvariante SQL Server 2008 EE kostenfrei bei MS herunterladen
  3. SQL Server installieren
  4. VMDKs mit der SQL DB, TransAktLogs und Backup an den temporären SQL mounten
  5. SQL Benutzer und -berechtigungen anlegen
  6. VCDB_table_cleanup_MSSQL.sql Skript anpassen und ausführen
  7. VMDKs wieder zurückmounten
  8. DB starten, vCenter Dienst starten!

Das Skript beinhaltet einen konfigurierbaren Teil:
/*
    VCDB_table_cleanup_MSSQL.sql,v 3.0 2009/08/31

    This script will delete data from designated tables in the VirtualCenter DB
    for 2.0.x , 2.5.x and vc4.0 versions.

    You are strongly advised to shut down the VirtualCenter server and make
    a complete backup of your database before running this script.

    VirtualCenter Server must be stopped while this script is running.

    Please see USER CONFIGURABLE PARAMETERS section below for options.

    In particular, you must set @DELETE_DATA = 1 in order to actually delete rows;
    this is a safety precaution.

    Directions: open this file with one of the following and execute:
        SQL Query Analyzer (SQL Server 2000) or
        SQL Server Management Studio (SQL Server 2005)
        SQL Server Management Studio (SQL Server 2008)

    Connect using the same DB login that VirtualCenter uses.

    The transaction log may fill up during this procedure if sufficient space
    is not available.  Monitor the transaction log size and usage with this command:

    dbcc sqlperf (logspace)

*/


IF OBJECT_ID('tempdb..#CLEANUP_VCDB') IS NOT NULL
    DROP TABLE #CLEANUP_VCDB
GO

SET NOCOUNT ON

DECLARE @VCUSER NVARCHAR(60)
DECLARE @VCUSERID INT
DECLARE @BATCH_SIZE INT
DECLARE @CUTOFF_DATE SMALLDATETIME
DECLARE @CUTOFF_DATE_S NVARCHAR(60)
DECLARE @DELETE_DATA BIT
DECLARE @CNT INT
DECLARE @TOT INT
DECLARE @SQL NVARCHAR(900)
DECLARE @FROM_VAL NVARCHAR(60)
DECLARE @WHERE_VAL NVARCHAR(900)


-- ######### USER CONFIGURABLE PARAMETERS ########################
-- 0 = COUNT ONLY; 1 = DELETE ROWS
SET @DELETE_DATA = 0

-- Use one of these methods to specifiy the data cutoff date
SET @CUTOFF_DATE = GETUTCDATE()-180
--SET @CUTOFF_DATE = '2007/01/01'

-- Number of rows to delete per transaction
SET @BATCH_SIZE = 10000


-- ######### END USER CONFIGURABLE PARAMETERS ####################
...
In diesem Fall dürfen es auch ein paar Nullen am Ende mehr sein, je nachdem wie viele Zeilen in dieser tabelle enthalten sind. Ferner ist die Variable zum Löschen auf den Wert "1" zu setzen.
Das Skript ruft man besten über die SQL Management Studio Anwendung auf. Da die Änderungen zunächst in den Transaktions-Logs abgelegt werden, sollte auf den entsprchenden VMDKs genügend (> 5GB) Speicherplatz zur Verfügung stehen.
Der Vorgang dauert allerdings ja nach Rechenleistung bis zu mehreren Stunden! Das muss man schon berücksichtigen, da das vCenter für diese Zeit nicht zur Verfügung steht.
Das Skript kann ich gerne per E-Mail weiterleiten, der Link auf der VMware Website ist leider verschwunden... .