Alles verloren ná uitbreiding disk in VMWare Workstation

[Verwijderd]

In VMWare Workstation was het nodig dat ik mijn virtuele disk ging uitbreiden voor mijn Windows Server 2016 VM. De knop "extend" in de VMWare settings was niet klikbaar. Volgens de software zou ik al mijn snapshots moeten verwijderen en dan zou het wel kunnen. Wat er niet bij stond was dat ik een foutmelding of dataverlies kan verwachten. Ik heb het advies van het programma opgevolgd en alle snapshots verwijderd. Na vele tientallen uren bezig te zijn geweest met deze VM (en andere in het netwerk) kan ik de VM nu niet meer opstarten. Omdat ik dit niet had verwacht had ik ook (heel naïef) geen backup gemaakt. Ik krijg nu elke keer een foutmelding bij het opstarten (zie screenshot). Ik weet nu echt niet meer wat ik moet doen. Ik zie het niet zitten om weer helemaal overnieuw te moeten beginnen. Kan ik op de een of andere manier de VM weer werkend krijgen?

Wat me opviel was dat wanneer ik voor "troubleshoot" kies (zie screenshot), en ik kies voor CMD dat ik dan mijn wachtwoord moet invullen. Mijn admin password wordt wél herkend, dus ergens moet het spul nog intact zijn.

Foutcode: 0xc00002e2

[Room42]

@Verwijderd Het betreft een domain controller?

Wat had je al gevonden, want het aantal resultaten is gigantisch: [google=0xc00002e2 vmware]

[Verwijderd]

Room42 schreef op zaterdag 23 juni 2018 @ 02:28:
@Verwijderd Het betreft een domain controller?

Wat had je al gevonden, want het aantal resultaten is gigantisch: [google=0xc00002e2 vmware]

Klopt, een DC inderdaad met de server roles DHCP, DNS, IIS, Router (NAT).

Ik denk dat ik het inmiddels weer werkend heb gekregen. Voor de zekerheid heb ik maar even een extra VM aangemaakt en de VMDK van de eerste gekopieerd zodat ik die voor de nieuwe VM kon gebruiken.

Ik heb deze instructie opgevolgd en het lijkt te werken. Eerst nog even snapshots e.d. maken van de andere VM's in mijn netwerk en dan ga ik vanmiddag de 'kapotte' VM proberen te fixen.

Fortunately, I found a better/simpler solution that usually works, or at least did for me.
- Boot into Directory Services Repair Mode (Troubleshoot / Startup Settings / Restart / Directory Services Repair Mode). It may do some repairs and reboot, requiring you to do this a second time.
- Login with a local admin account, since AD is not available.
- Delete (or rename) C:\Windows\NTDS\*.log.
And reboot normally.

However, you may also want to defrag the database while in DSRM:
- Open a Command Prompt (Win-R, CMD, Enter). Type NTDSUTIL and press Enter.
Type "activate instance ntds" and press Enter.
Type "Files" and press Enter.
Type "Info" and press Enter. Verify the folder is actually C:\Windows\NTDS.
Type "Compact to " and press Enter. I created C:\Windows\NTDS\Temp and used that.
Copy the new file Ntds.dit in the temp folder over top of the old one in NTDS, and delete all the *.log files.
Reboot normally.

Het mooie is dat Active Directory nog intact lijkt te zijn na bovenstaande instructie (maar anders had ik gelukkig nog een andere DC voor fouttolerantie).

[ Voor 18% gewijzigd door Verwijderd op 23-06-2018 03:30 ]

[Wim-Bart]

Je weet dat je alleen van 1 DC een snapshot mag maken en niet van een tweede wanneer je die hebt. Wanneer je namelijk een tweede DC hebt en je doet daar een roll-back dan is je AD definitief corrupt.

Overigens, snapshots in VMware zijn niet bedoeld als backup. Snapshots maken de boel traag.

[CMD-Snake]

Verwijderd schreef op zaterdag 23 juni 2018 @ 02:04:
Wat er niet bij stond was dat ik een foutmelding of dataverlies kan verwachten. Ik heb het advies van het programma opgevolgd en alle snapshots verwijderd. Na vele tientallen uren bezig te zijn geweest met deze VM (en andere in het netwerk) kan ik de VM nu niet meer opstarten.

Een virtuele harde schijf vergroten is een redelijk standaard handeling in VMWare (workstation), back-ups zouden niet nodig moeten zijn. Je vergroot het getal van de virtuele schijf en daarna moet je even in Windows de disks opnieuw scannen en de loze ruimte in gebruik nemen.

Je constructie met al die snapshots snap ik niet. Snapshots moet je alleen maken als je denkt dat een verandering slecht uit kan pakken. Na het verifiëren van de uitkomst kan of een revert doen of mergen om de wijziging permanent te maken. Steeds snapshots maken en de differencing disks opstapelen geeft een hoop ellende.

[Room42]

offtopic:
Ik heb het idee dat Dhr. @Verwijderd nog aan het leren is, mannen. Dus dat nog niet alles gaat zoals we op enterprise level zouden doen, is redelijk logisch. Tips om hem naar een hoger niveau te tillen zullen vast welkom zijn, maar dan zou een onderbouwing wel helpen.

[Verwijderd]

CMD-Snake schreef op zaterdag 23 juni 2018 @ 12:11:
[...]


Een virtuele harde schijf vergroten is een redelijk standaard handeling in VMWare (workstation), back-ups zouden niet nodig moeten zijn. Je vergroot het getal van de virtuele schijf en daarna moet je even in Windows de disks opnieuw scannen en de loze ruimte in gebruik nemen.

Je constructie met al die snapshots snap ik niet. Snapshots moet je alleen maken als je denkt dat een verandering slecht uit kan pakken. Na het verifiëren van de uitkomst kan of een revert doen of mergen om de wijziging permanent te maken. Steeds snapshots maken en de differencing disks opstapelen geeft een hoop ellende.

CMD-Snake schreef op zaterdag 23 juni 2018 @ 12:11:
[...]


Een virtuele harde schijf vergroten is een redelijk standaard handeling in VMWare (workstation), back-ups zouden niet nodig moeten zijn. Je vergroot het getal van de virtuele schijf en daarna moet je even in Windows de disks opnieuw scannen en de loze ruimte in gebruik nemen.

Je constructie met al die snapshots snap ik niet. Snapshots moet je alleen maken als je denkt dat een verandering slecht uit kan pakken. Na het verifiëren van de uitkomst kan of een revert doen of mergen om de wijziging permanent te maken. Steeds snapshots maken en de differencing disks opstapelen geeft een hoop ellende.

Bedankt voor de informatie. Dat wist ik niet. Maar dat verklaart ook waarom mijn VM trager was dan mijn andere DC, die minder snapshots heeft.

Wat je precies bedoelt met "daarna moet je even in Windows de disks opnieuw scannen en de loze ruimte in gebruik nemen". Ik neem aan dat je gewoon refereert naar Disk Management? Hoe dan ook, het enige wat ik had gedaan was de grootte van de virtuele disk wijzigen en daarna bootte Windows niet meer op. Nu het weer middag is ga ik weer aan de slag om het werkend te krijgen. Vannacht had ik alleen even de oplossing getest op een clone.

[Marcelvdsteen]

Ik weet niet of het nog moet, maar vroeger wel eens problemen gehad als ik alle ruimte toewees. Een advies was toen enkele MB’s vrij laten bij vergoten van het volume. Dat doe ik nog altijd in zowel esx als hyperv machines

[Verwijderd]

Marcelvdsteen schreef op zaterdag 23 juni 2018 @ 15:24:
Ik weet niet of het nog moet, maar vroeger wel eens problemen gehad als ik alle ruimte toewees. Een advies was toen enkele MB’s vrij laten bij vergoten van het volume. Dat doe ik nog altijd in zowel esx als hyperv machines

Bedankt voor de tip. Ik had zelf alle ruimte gebruikt voor het volume. Ik moet straks een andere partitie aanmaken dus dan laat ik wat ruimte onbenut.

[synoniem]

Verwijderd schreef op zaterdag 23 juni 2018 @ 15:22:
[...]


[...]

Hoe dan ook, het enige wat ik had gedaan was de grootte van de virtuele disk wijzigen en daarna bootte Windows niet meer op. Nu het weer middag is ga ik weer aan de slag om het werkend te krijgen. Vannacht had ik alleen even de oplossing getest op een clone.

De reden dat het waarschijnlijk fout gegaan is omdat je de snapshots weggegooid hebt. Als je de snapshots merged en daarna de disk vergroot zou het in 1 keer moeten werken. Moet je inderdaad in Windows ook de gecreëerde ruimte toevoegen via diskmanagement.

[Verwijderd]

synoniem schreef op zaterdag 23 juni 2018 @ 15:29:
[...]

De reden dat het waarschijnlijk fout gegaan is omdat je de snapshots weggegooid hebt. Als je de snapshots merged en daarna de disk vergroot zou het in 1 keer moeten werken. Moet je inderdaad in Windows ook de gecreëerde ruimte toevoegen via diskmanagement.

Hoe bedoel je mergen? Het laatste punt in de snapshot lijst is toch gewoon de leidende? Ik heb even een screenshot gemaakt van een van mijn andere VM's en daar wat snapshots geselecteerd, maar ik zie niet iets van mergen.

Van wat ik net heb gelezen is dat je de snapshots moet verwijderen. Ergens anders staat weer dat je alle snapshots in één keer moet verwijderen. Ik had ze één voor één verwijderd. Kan iemand hier meer duidelijkheid over scheppen?

[Fish]

Verwijderd schreef op zaterdag 23 juni 2018 @ 17:08:
[...]

Hoe bedoel je mergen? Het laatste punt in de snapshot lijst is toch gewoon de leidende? Ik heb even een screenshot gemaakt van een van mijn andere VM's en daar wat snapshots geselecteerd, maar ik zie niet iets van mergen.
[afbeelding]
Van wat ik net heb gelezen is dat je de snapshots moet verwijderen. Ergens anders staat weer dat je alle snapshots in één keer moet verwijderen. Ik had ze één voor één verwijderd. Kan iemand hier meer duidelijkheid over scheppen?

Een snapshot creert een punt in tijd waar je naar terug kan springen. alles wat daarna gebeurt word apart bijgehouden. (de changes) gooi je de changes weg dan ja ..

Als je 10 snaphots hebt moet de vm door alle snapshots om de huidige image te zien. dat maakt hem traag.

Dat voorkom je door een snapshot te mergen als alles goed loopt

http://www.sysprobs.com/merge-snapshots-vmware-workstation-7

[ Voor 3% gewijzigd door Fish op 23-06-2018 17:21 ]

[Dennism]

Op de juiste wijze verwijderen is gelijk aan mergen. Ik werk voornamelijk met vSphere en niet met VMware workstation. Maar op het geposte screenshot lijkt het wel of je 2 snapshot chains hebt. Het ziet er in ieder geval vreemd uit.

Maar zeker in een omgeving met meerdere DC"s zoals je aangeeft wil je niet lopen te prutsen met snapshots. Voordeel is wel dat het eigenlijk niet uit mag maken als er in een omgeving met meerdere DC's iets mis gaat. Wanneer je nog kan netjes demoten wanneer er iets mis gaat, mocht dat niet meer kunnen netjes opruimen via alternatieve methoden. Nieuwe VM opspinnen, promoten tot DC en je kan weer verder. Tenzij je natuurlijk ook allerlei andere zaken op je DC zet, waardoor je ze niet meer eenvoudig kan vervangen (niet aan te raden).

[Verwijderd]

Dennism schreef op zaterdag 23 juni 2018 @ 17:31:
Op de juiste wijze verwijderen is gelijk aan mergen. Ik werk voornamelijk met vSphere en niet met VMware workstation. Maar op het geposte screenshot lijkt het wel of je 2 snapshot chains hebt. Het ziet er in ieder geval vreemd uit.

Maar zeker in een omgeving met meerdere DC"s zoals je aangeeft wil je niet lopen te prutsen met snapshots. Voordeel is wel dat het eigenlijk niet uit mag maken als er in een omgeving met meerdere DC's iets mis gaat. Wanneer je nog kan netjes demoten wanneer er iets mis gaat, mocht dat niet meer kunnen netjes opruimen via alternatieve methoden. Nieuwe VM opspinnen, promoten tot DC en je kan weer verder. Tenzij je natuurlijk ook allerlei andere zaken op je DC zet, waardoor je ze niet meer eenvoudig kan vervangen (niet aan te raden).

Bij het verwijderen van de snapshots had ik volgens mij eerst de nieuwste verwijderd in de snapshots manager (niet in explorer!) en daarna de oudste. De laatste aanpassing die ik had gedaan op mijn server is nog intact. Alle andere VM's stonden op dat moment uit.

Deleting last snapshot (D) will remove it completely and it will not be merged with the previous one, in general we can merge in-between snapshots by deleting them , otherwise it will not be merged.

. Ik heb dus (waarschijnlijk) niet gemerged, maar gewoon gedeletet.

[ Voor 17% gewijzigd door Verwijderd op 23-06-2018 19:58 ]

[Raoul.TLS]

Kan je de disk niet aan een andere vm koppelen en data terug halen

[CMD-Snake]

Verwijderd schreef op zaterdag 23 juni 2018 @ 15:22:
Bedankt voor de informatie. Dat wist ik niet. Maar dat verklaart ook waarom mijn VM trager was dan mijn andere DC, die minder snapshots heeft.

Snapshots zijn de doodsteek voor performance. Zeker als de differencing disk heel groot is geworden zal de VM traag worden. Mergen gaat daarna ook steeds moeilijker.

Ik heb die screenshot gezien die je gepost heb, daar schrik ik serieus van. Dat zijn zoveel disks die nu op elkaar stapelen daarvoor. Performance zal slecht zijn, maar als een van die bestandjes een ongeluk heeft breekt de hele keten. Je VM is dan morsdood.

Een snapshot is alleen bedoeld als een tijdelijk iets. Als ze niet meer nodig zijn gelijk opruimen.

Dennism schreef op zaterdag 23 juni 2018 @ 17:31:
Op de juiste wijze verwijderen is gelijk aan mergen. Ik werk voornamelijk met vSphere en niet met VMware workstation. Maar op het geposte screenshot lijkt het wel of je 2 snapshot chains hebt. Het ziet er in ieder geval vreemd uit.

Ik denk dat het komt door de resolutie. Ik hoop het tenminste...

Verder werkt Workstation hetzelfde als vSphere, qua gebruik en interface is het vrijwel hetzelfde.

[Verwijderd]

Raoul.TLS schreef op zaterdag 23 juni 2018 @ 19:57:
Kan je de disk niet aan een andere vm koppelen en data terug halen

De DC waar het om gaat is uniek. De tweede heeft bijv. niet 2 NIC's, geen NAT-router geconfigureerd en misschien nog wel wat dingen. Middels DSRM is het inmiddels gelukt.

CMD-Snake schreef op zondag 24 juni 2018 @ 00:08:
[...]
Ik heb die screenshot gezien die je gepost heb, daar schrik ik serieus van. Dat zijn zoveel disks die nu op elkaar stapelen daarvoor. Performance zal slecht zijn, maar als een van die bestandjes een ongeluk heeft breekt de hele keten. Je VM is dan morsdood.

Een snapshot is alleen bedoeld als een tijdelijk iets. Als ze niet meer nodig zijn gelijk opruimen.

Na elke paragraaf uit mijn boek maakte ik een snapshot. Ik zal nu na elke paragraaf ook de oude snapshot verwijderen.

Alles werkt nu in ieder geval weer naar behoren voor zover ik kan zien.

[|sWORDs|]

Zelfs een enkele snapshot heeft al een flinke impact op de performance (tot zo’n 50%), best practice is om niet meer dan drie snapshots te hebben en verder zo min mogelijk (bij voorkeur 0).

[Raoul.TLS]

Als je op SSD storage draait alt het mee
Maar zolang het tijdelijk is max een week of maand

[CMD-Snake]

Verwijderd schreef op zondag 24 juni 2018 @ 01:31:
Na elke paragraaf uit mijn boek maakte ik een snapshot. Ik zal nu na elke paragraaf ook de oude snapshot verwijderen.

Of doe een revert. Als je een cursus volgt is dat soms beter omdat sommige oefeningen je destructieve wijzigingen laten aanbrengen om iets te demonstreren.

Raoul.TLS schreef op zondag 24 juni 2018 @ 09:00:
Als je op SSD storage draait alt het mee

Het blijft geen best practice voor virtualisatie om je snapshots zo op te bouwen. Bovendien als in die keten van snapshots eentje corrupt raakt is de hele virtuele machine stuk.

[Question Mark]

Wim-Bart schreef op zaterdag 23 juni 2018 @ 04:53:
Je weet dat je alleen van 1 DC een snapshot mag maken en niet van een tweede wanneer je die hebt. Wanneer je namelijk een tweede DC hebt en je doet daar een roll-back dan is je AD definitief corrupt.

Dat was vroeger zo, maar tegenwoordig zijn daar safeguards voor. Sinds Windows 2012 volledig supported.

Windows Server 2012 now supports DC cloning and snapshot restore of domain controllers. The requirements to support the new feature are:

• Hypervisor that supports VM-GenerationID. Window Server 2012 Hyper-V supports VM-GenerationID. If using a third party Hypervisor, check with the vendor if their latest version supports this feature.
• The source virtual domain controller must be running Windows Server 2012.
• A Windows Server 2012 PDC Emulator FSMO Role must be running and available for the cloned DC

.

VMWare Workstation ondersteunt dit ook gewoon:

https://dirteam.com/sande...pporting-vm-generationid/

Neemt niet weg dat ik absoluut geen fan ben van snapshots. Leuke feature als je een change uitvoert, maar verwijder ze zo snel mogelijk...