List “Missing” guest in SCVMM

Problem

You want to create a list of all the guests listed as “Missing” in System Center Virtual Machine Manager 2012. Missing guest are usually references to guest that were deleted manually outside of VMM. To fix this, you have to delete the guests manually from VMM. But before you delete them, it is a good idea to get input on the list, just in case one of them shouldn’t be missing. You can of course use a filter in SCVMM to display them on-screen, but I was not able to find an easy way to grab the list as text from the GUI.

Solution

Use Powershell! Run the following command in your VMM Powershell console:

Get-VM| Where-Object {$_.Status -eq 'Missing'} | Sort-Object Hostname | Select-Object HostName, Name, ComputerName, Status | Export-Csv .\Missing-guest-list.csv -NoTypeInformation

This will give you an excel compatible csv file with a list of missing VMs/guests. If you want the list to include all of the guests, regardless of status, just remove the Where-object clause like this:

Get-VM| Sort-Object Hostname | Select-Object HostName, Name, ComputerName, Status | Export-Csv .\Missing-guest-list.csv -NoTypeInformation

Or you can change ‘Missing’ to another status like “Stopped”, “Saved State”, “Unsupported Cluster Configuration” and so on.

 

 

Redundancy versus Single Points of Failure

There seems to be a widespread misconception in the IT community regarding Single Points of Failure: as long as you have N+1 redundancy in all your components, you no longer have a single point of failure. This is not necessarily correct, and can lead to a very bad day when you discover that your “bullet proof” datacenter or system design turns out to be one big basket with all your eggs in it. The fact of the matter is that adding redundancy to a component will only reduce the chance of failure, it won’t make it impossible for the component to fail. Take a MSSQL failover cluster for instance, be it Active-Active or the more common Active-Passive. Compared to a stand-alone server it offers far better redundancy, and it will limit maintenance downtime to a bare minimum. But on its own it is still a single point of failure, in fact it has several single points of failure: shared network/IP, shared storage and the cluster service itself to mention a few. I have seen all of the above fail in production, resulting in complete failure of the cluster. Especially on Win2003 and earlier, a poorly configured cluster could easily cause more problems than a stand-alone server ever would, but even if everything is set up and maintained properly, bad things will happen sooner or later.

Continue reading “Redundancy versus Single Points of Failure”

Prosessor Overcommit på VMware

Om feilsøking av prosessorrelaterte ytelsesproblemer på virtuelle gjester som kjører i et VMware miljø.

Jeg har skrevet en del om hvordan tilgang på fysiske minne- og prosessorressurser påvirker ytelsen til virtuelle gjester på generell basis her og her. Som jeg nevner er det primært mengden fysisk minne som avgjør hvor mange/store gjester man kan ha på en vertsmaskin. Dersom man først oversubscriber, som gjerne er hele poenget med virtualisering av servere, vil man selvsagt oversubscribe prosessorene også. Når det gjelder minne er det egentlig ganske enkelt å se når det oppstår overcommit, siden det medfører såpass store ytelsesmessige konsekvenser. På prosessorsiden oppstår feilen dog mer gradvis. Jeg har i det siste jobbet litt med å identifisere årsak til en del rare problemer på virtuelle gjester, og har i den sammenheng forsøkt å sette meg inn i hvordan man på VMWare vCenter 4 henter inn de nødvendige grunnlagsdata og analyserer disse.

Continue reading “Prosessor Overcommit på VMware”

Klart det kan virtualiseres!

Det er svaret man får i 19 av 20 tilfeller om man spør noen som skal ha greie på virtualisering om en gitt tjeneste kan virtualiseres. Og de har stort sett rett. Problemet er at man stiller feil spørsmål. Isteden må man spørre seg: “Bør jeg virtualisere tjeneste x i mitt virtualiseringsmiljø? Og “Passer det med min virtualiseringsstrategi?”

Det er nemlig ikke gitt at forskjellige tjenester passer sammen i det samme virtuelle miljøet. Særlig ikke om man har satset og investert tungt i automatisk lastbalansering og høy oppetid.

Virtualisering er fremtiden, ingen tvil om det. Det gjør at man kan utnytte hardware mye mer effektivt en før, man kan spare store penger på strømutgifter og hardwarekostnader, og man kan oppfylle målsetninger om grønn IT og lavere karbonfotavtrykk. Det er ikke uvanlig å kjøre over 20 virtuelle servere på en fysisk vertsmaskin. Nå skal man riktignok ikke legge for mye i slike tall, for dersom man måtte kjøpe fysiske maskiner isteden hadde man sannsynligvis hatt færre servere med flere tjenester på hver server.

Man får også andre fordeler, som muligheten til å skifte ut hardware uten at serveren merker det, og muligheten til å flytte en virtuell server mellom flere vertsmaskiner mens den går slik at vedlikehold blir enklere. Det er rett og slett et stort fremskritt, noe som gjør at man lett sier at alt skal virtualiseres så langt det lar seg gjøre. Og det kan man stort sett oppnå, men det er ikke sikkert at det alltid er like lurt. Dersom man har et cluster med vertsmaksiner der gjennomsnittsserveren er tildelt 5GiB minne er det ikke sikkert at man bør legge inn servere som drar 50GiB i samme cluster.

Jeg skal ikke påstå å ha inngående kjennskap til virtualiseringsplattformer, men jeg har jobbet med optimalisering av Windows-servere siden NT 4, og en server med en gitt tjeneste trenger en viss mengde ressurser uansett om den er fysisk eller virtuell. Denne artikkelen handler mest om mine erfaringer med drift av forskjellige servertyper i virtuelle miljø. Se også artikkelen om Memory Overcommit der jeg skriver om problemer som kan oppstå om man ikke følger med på hvor mye minne som er i bruk på vertsmaskinene.

Continue reading “Klart det kan virtualiseres!”

Virtual Server memory Oversubscription og Overcommit, en oppskrift på katastrofe?

Etter å ha feilsøkt en del sære feil på virtuelle maskiner i et ESX miljø, bestemte jeg meg for å finne ut mer om hvordan minnehåndtering fungerer i virtuelle miljøer generelt og VMWare spesielt. Jeg har ikke så mye erfaring med oppsett av virtuelle miljøer for produksjon. For meg er det mest en plattform som en del av serverne jeg drifter kjører på, og som jeg må forholde meg til fra den siden. Etter å ha forsket litt på saken kom jeg frem til at en del av mine problemer nok skyldtes Memory Overcommit og det beslektede Memory Oversubscription. Memory Overcommit er et mye brukt uttrykk som virker å ha forskjellig betydning ut fra hvilken bakgrunn man har, derfor begynner jeg med å definere begrepene slik jeg ser dem.

Continue reading “Virtual Server memory Oversubscription og Overcommit, en oppskrift på katastrofe?”