Zoek op trefwoord, naam of systeem:

Blog

  • 25
    november
    2013
    Marcel Funke, Technology Professional

    VDI-werkplek: Omgevallen bits

    Dat er soms onvoorspelbare dingen gebeuren op een VDI-werkplek was al bekend. Dat er problemen op alle VDI-werkplekken, in plaats van één VDI-werkplek, voorkomen was ook al bekend. Dat er soms ergens in de VDI-omgeving een aantal bits omvallen of niet goed meekomen en er daardoor problemen optreden op slechts een deel van de VDI-werkplekken is minder bekend. Deze blog beschrijft wat recent bij een klant van ConoScenza heeft plaatsgevonden en hoe het probleem getroubleshoot en getackled werd.

    Een dag na de release van een nieuwe VDI-image kwamen een aantal meldingen binnen over printers die niet meer beschikbaar zouden zijn. De dag ervoor waren er nog geen problemen of meldingen geweest van dit kaliber. Daarnaast bestond het probleem dat de printers niet opnieuw konden worden toegevoegd. Het vervelende was dat niet iedereen dit probleem had.

    Waar ga je dan naar op zoek? Je bekijkt alle componenten die van invloed zouden kunnen zijn op de fout: is de printer spooler service wel gestart? Zijn er fouten op userworkspacemanagementniveau bij het meenemen of opslaan van de printer gerelateerde gegevens? De print spooler service was inderdaad niet gestart, maar kon ook niet worden gestart. Op userworkspacemanagementniveau waren er geen afwijkende zaken te zien tussen een gebruiker die wél en een gebruiker die géén printergerelateerde problemen had. Waarom waren er op de ene VDI-werkplek dan geen problemen en op de andere VDI-werkplek wel?

    Vanuit de management console waarmee de VDI-desktops beheerd worden, was het volgende te zien. De gebruikers die problemen ondervonden, maakten verbinding met een virtuele desktop op dezelfde Hyper-V server. Handmatig een gebruiker naar een VDI-desktop op deze Hyper-V server koppelen, leverde inderdaad hetzelfde probleem op. Was er misschien iets aan de hand met de Hyper-V server? Om dat uit te sluiten werd de problematische Hyper-V server uit de pool van Hyper-V servers gehaald en werden binnen een VDI-testgroep een honderdtal VDI-desktops aangemaakt op basis van de vorige release van het VDI-image. Een gebruiker toekennen aan deze VDI-testgroep en laten werken met deze vorige release leverde inderdaad geen problemen op. Gebruikers hadden beschikking over de printers en konden zonder problemen printers toevoegen of verwijderen.

    Zou het probleem dan zitten in de gekopieerde parent-VHD? Simpel gezegd, een parent-VHD is een kopie van het VDI-image die op elke hypervisor (in dit geval een Hyper-V-server) aanwezig dient te zijn om er gekloonde VDI-desktops van te kunnen maken. Eerst werd gecontroleerd of de parent-VHD wel aanwezig is op de Hyper-V server. Die was aanwezig. Het tijdstip waarop het bestand is aangemaakt en attributen, zoals rechten op het bestand en de bestandsgrootte, waren identiek aan de parent-VHD’s op de overige Hyper-V servers. Tot zover de zichtbare overeenkomsten tussen de parent-VHD’s.

    Om de minder zichtbare overeenkomsten inzichtelijk te maken werden met de Microsoft File Checksum Integrity Verifier de parent-VHD’s bekeken. De Microsoft File Checksum Integrity Verifier is een commandlinetool die MD5 of SHA1 cryptografische hashes voor bestanden kan berekenen. Op deze manier kan gekeken worden of bestanden écht identiek aan elkaar zijn. Identieke bestanden zullen dan dezelfde hash moeten dragen.

    De hashes bleken verschillend te zijn. Dat zou met het probleem te maken kunnen hebben. Dat kon maar op één manier gecontroleerd worden. De Hyper-V server werd uit de Hyper-V serverpool gehaald en de foutieve parent-VHD en virtuele desktops werden verwijderd. Het vervolgens opnieuw toevoegen van de Hyper-V server aan de Hyper-V serverpool, zorgde ervoor dat de parent-VHD opnieuw werd gekopieerd naar de Hyper-V server. De kopieerslag van de parent-VHD verliep zonder problemen en de hashes waren gelijk. De VDI-desktops werden vervolgens weer automatisch en zonder problemen aangemaakt. Bij het aanloggen op de eerder problematische Hyper-V server waren de print(spooler)problemen nu niet meer aanwezig.

    Het omvallen, of niet helemaal goed aanwezig zijn, van één of meer bits had dus gevolgen voor de werking van de VDI-werkplek. Mede als gevolg van de inspanningen die dit onderzoek in beslag nam, is besloten de hash-controle in het vervolg na elke maandelijkse nieuwe VDI-release automatisch uit te laten voeren en melding te geven wanneer er afwijkingen zijn.

mm

Auteur: Marcel Funke, Algemeen directeur

Trefwoorden:

Email Marcel Funke

Lees alle blogberichten van Marcel Funke

Deel dit bericht

Geen reacties

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *