Orphaned VM’s in VMWare vCenter Server
Dat was even schrikken toen ik zag dat de VMWare backup niet goed had gelopen !
Er wordt een backup van 60 Virtual Machines gemaakt en 21 zijn er met een foutmelding uit geknald met verschillende foutmeldingen :
De foutmeldingen :
Error: An error occurred performing query ‘DatastoreQuery’. Error: Unable to connect to the remote server
Error: An error occurred performing query ‘VirtualMachineConfigurationQuery’. Error: Unable to connect to the remote server
Object reference not set to an instance of an object
Error: API Call failed with message: A general system error occurred: vim.fault.GenericVmConfigFault
Error: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server
Hebben allemaal met de connectiviteit naar de vCenter Server te maken en diens hosts.
Toen maar even ingelogged op de vCenter Server om te checken wat er gaande was.
Ten eerste zag ik dat de 6 ESX Servers wel online waren, geen alarms of warnings.
Wat wel opviel was dat ALLE Virtual Machines als Powered Off zichtbaar waren met achter de VM Naam “(Orphaned)”
Onderstaand plaatje is niet een screenshot van ons serverpark maar een ander.
De “VM1 (orphaned)” is dus exact de melding die ik op alle 60 Virtual Machines kreeg.
Uiteraard heb ik de vCenter logbestanden nagekeken, maar daar was niets te zien. Ook viel op dat de Server statussen niet up to date waren.
Misschien was er iets aan de hand met de Management Agents op de ESX servers ?
Op alle ESX servers heb ik voor de zekerheid de Management Agents geherstart, maar dat haalde helaas niks uit.
Ook werd de vSphere Client er continue uitgegooid waardoor deze steeds weer opnieuw gestart moest worden.
Ondanks dat vSphere een enorme lading problemen presenteerde, vertelde de monitoring mij dat er niets aan de hand was !
Alle machines en alle services draaiden netjes.
Even ging door mijn gedachte om het complete serverpark te gaan rebooten, maar dat is zo goed als onmogelijk aangezien wij een 24/7 bedrijf zijn.
Op zo’n moment ga je dan dus zaken uitsluiten om voor een zo klein mogelijke impact te zorgen bij het troubleshooten :
– ALLE VM’s staan als orphaned, dus er is een probleem met ALLE ESX Hosts ?
– De ESX Hosts reageren allemaal netjes, rechtstreeks met vSphere connecten werkt beter, maar niet 100% (i.v.m. vCenter Agent)
– De monitoring zegt dat alles online is, en een quick check wijst dat inderdaad uit. Alles draait gewoon.
– vCenter Server crasht steeds, krijgt geen geüpdate data van de ESX Hosts.
– Connectiviteit is in orde
– Het StoreVirtual cluster draait ook gewoon zonder problemen.
Dit alles terug redenerend kan ik niet anders dan de conclusie trekken dat het probleem centraal ligt, dus op de vCenter Server.
Tenslotte kan niet alles opeens tegelijkertijd kapot gaan.
Eventlogs van Windows zelf gecontroleerd en dat was al snel BINGO !
Er kwamen vermeldingen voorbij over de SQL Database van de vCenter Server :
could not allocate space for object ‘dbo.vpx_host_vm_config_option’.’pk_vpx_host_vm_config_option’ in database…..
Could not allocate space…..dat klinkt alsof de database vol zit en er dus geen data meer bijgeschreven kan worden.
de VIM_SQLEXP SQL Instantie is een MS SQL Express instantie welke tot maximaal 10 GB grote databases kan handlen.
Dit gecontroleerd door in te loggen met de SQL Studio Express en bekeken hoeveel data er in de database stond.
Inderdaad was deze met 10 GB Data gevuld en liep tegen zijn max van de SQL Express versie !
Dat verklaard natuurlijk een hoop, maar hoe ga je nu die database kleiner maken zonder dat je je config kwijt raakt ?
Gelukkig is dit een bekend “probleem” bij VMWare en er wordt ook een oplossing aangeboden.
Deze oplossing houdt in dat je oude data verwijderd, maar alle configs en belangrijke zaken behoudt en bestaat uit slechts enkele stappen :
Voordat je begint : Maak EERST een backup van je vCenter Database !!!!!!!
Stap 1:
Stop alle vCenter Server Services
Stap 2:
Log in met SQL Studio Express op de vCenterdatabase en selecteer VIM_VCDB (1) en druk op New Query (2).
Stap 3:
Voer in de query het volgende in :
Create Table #Temp(Name sysname, rows int, reserved varchar(100), data varchar(100), index_size varchar(100), unused varchar(100))exec sp_msforeachtable ‘Insert Into #Temp Exec sp_spaceused ”?”, ”true”’ Select * From #Temp
En druk op Execute
Stap 4:
Maak een nieuwe query en voer daar het volgende in :
alter table VPX_EVENT_ARG drop constraint FK_VPX_EVENT_ARG_REF_EVENT, FK_VPX_EVENT_ARG_REF_ENTITY alter table VPX_ENTITY_LAST_EVENT drop constraint FK_VPX_LAST_EVENT_EVENT
truncate table VPX_TASK
truncate table VPX_ENTITY_LAST_EVENT
truncate table VPX_EVENT
truncate table VPX_EVENT_ARG
alter table VPX_EVENT_ARG add
constraint FK_VPX_EVENT_ARG_REF_EVENT foreign key(EVENT_ID) references VPX_EVENT (EVENT_ID) on delete cascade, constraint FK_VPX_EVENT_ARG_REF_ENTITY foreign key (OBJ_TYPE) references VPX_OBJECT_TYPE (ID) alter table VPX_ENTITY_LAST_EVENT add constraint FK_VPX_LAST_EVENT_EVENT foreign key(LAST_EVENT_ID) references VPX_EVENT (EVENT_ID) on delete cascade
En druk op Execute.
Dit zorgt er voor dat de Event History verwijderd wordt.
Stap 5:
In nog een nieuwe query voeren we het volgende in :
SELECT Count (*) FROM VPX_TEXT_ARRAY
WHERE NOT EXISTS(SELECT 1 FROM VPX_ENTITY WHERE ID=VPX_TEXT_ARRAY.MO_ID)
De VPX_TEXT_ARRAY houdt de informatie bij van de VM’s en Datastore informatie welke inclusief een samenvatting van de VM configs. Deze query is om te controleren hoeveel tabellen er zijn en wat de grootte is van VPX_TEXT_ARRAY
Stap 6:
In een nieuwe en laatste query voeren we de query in om oude data uit de VPX_TEXT_ARRAY te verwijderen :
De laatste stap is het starten van de vMWare Services.
Dat was inderdaad het geval !
Echter bij een heel aantal VM’s stond er een rood uitroeptekentje bij en het raadplegen van de Events vermeldde een probleem met de HA config :
Noteer van tevoren even wat de exacte en juiste settings zijn omdat deze verwijderd worden !
Zet het vinkje uit bij “Turn On vSphere HA” en druk op OK.
