Beste Vmug-ers,

De issue is als volgt. Vorig jaar december heeft iemand een snapshot van een virtuele server gemaakt. Deze is echter nooit verwijderd.

Nu wil ik ze graag weer commiten met elkaar om zo een nettere omgeving te krijgen. Echter zit ik met de doorlooptijd die hiermee gemoeid is.

Zie hieronder het plaatje hoe het op file level eruit ziet.



Ik weet niet als de specs ertoe doen van de VM maar dit zijn ze:
2 cpu en 3 gig mem

De esx omgeving is 3.5 laatste update
Vc versie laatste van 2.5

Wat is mijn vraag

Er zijn twee mogelijkheden wat betreft snapshot terugzetten. Offline en online.

Nu vraag ik me af wat de doorlooptijd is bij:
1) ik zet de server uit en doe dan remove snapshot
2) ik laat de server aan staan en doe remove snapshot. Verder hoeveel performance kost dit op de VM? Kunnen de gebruikers uberhaupt nog wel werken?

Verder vraag ik me af hoeveel beschikbare ruimte ik moet hebben om dit door te voeren (Staat me iets van bij dat je snapshotsize 2x aan beschikbare ruimte moet hebben).

Zijn er verder nog officiële documenten wat betreft doorlooptijden van het removen van snapshots, of is er een vuistregel?

Alvast bedankt voor het meedenken

Bij het verwijderen van een snapshot wordt volgens mij eerst de data gecommit naar de onderliggende vmdk en delta files. Aangezien je maar 1 snapshot hebt zal de ruimte van de snapshot eerst naar de vmdk worden gezet voordat de de delta file wordt verwijderd. Deze ruimte zal je minimaal moeten hebben.

Bij het verwijderen van een snapshot zal niet alleen de vm performance problemen gaan ondervinden, maar alle vm's op de esx server. Tevens kan je storage tegen i/o problemen lopen.

Persoonlijk zou ik de vm uitzetten en in de avonduren de snapshot verwijderen. Let wel op de backup dat dan eventueel loopt.

Dit zou gewoon live kunnen, ik zie dat het maar om een hele kleine snapshot (2 gb) gaat en ben je er in korte periode van af. Zorg er in ieder geval voor dat je 10 ~15% schijfruimte vrij hebt op je datastore.

En het gaat ook maar om een enkele snapshot, echt een probleem heb je niet dus.

ESX 4.1 heeft een nieuwe manier van snapshots verwijderen met de "delete all" functie. In oudere versies van ESX (jonger dan 4.1) snapshot: 4 > 3 , 3 > 2 , 2, 1 , 1 > .vmdk , in ESX 4.1 is het 4 > .vmdk , dit scheelt schijfruimte, calculatie tijd, minder handelingen en troubleshooten. Echter is bovenstaande niet bij jullie van toepassing.

Zorg bijvoorbeeld op je omgeving dat je een daily health script heb draaien die laat zien of er actieve snapshots aanwezig zijn. Deze kan per email naar je toe worden gezonden (algemeen postvak of distributiegroep) dan weet iedereen waar die aan toe is.

http://communities.vmware.com/docs/DOC-9842
http://www.virtu-al.net/featured-scripts/vcheck/

Of gewoon een alarm instellen wanneer een VM in een snapshot leeft dat er een Alarm af moet gaan met een bepaalde functie. (Bijv. email):

http://www.youtube.com/watch?v=gl0VmmKN ... _embedded#!

http://www.virtu-al.net/2009/06/22/powe ... preminder/

Bij grote snapshots kan je een "timed out" krijgen binnen je host/vCenter. Ga geen rare fratsen uithalen dit te repareren want het systeem is onder water druk bezig met het committen/verwijderen. Geduld is een schone zaak

Bij het verwijderen zal je VM ietswat trager kunnen functioneren

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Het gaat om 2 disksnapshots van 2 en 11 GB en een vswp verpakt in de vmsn file.

13 GB Snapshots consolideren zou niet vreselijk lang moeten duren, maar:
- Performance VM kan behoorlijk inzakken
- Performance ESX-host zal behoorlijk inzakken, waarschijnlijk met een time-out in de VIClient als gevolg.
- Verwijder snapshot vanuit VIClient verbonden naar de ESX-host, niet naar de vCenter server.
- Probeer andere running VM's op de ESX-host te migreren naar andere ESX-hosts om de impact te minimaliseren.

_________________
Blog: Virtual Lifestyle

Whoeps, 13 inderdaad overheen gekeken

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Whow wat een reacties, dank je hiervoor.

Ok, het gaat dus niet lang duren. Laatst had ik hier een consultant en die gaf aan dat het online weleens 3 dagen kon duren voordat de snapshot weg was. ik had daar zelf al mijn vraagtekens bij en dat word door jullie ook beaamd gelukkig.

Enige wat ik mis is dat het nu nog een beetje vaag klinkt (duurt niet lang).

Ik ga voor de optie voor offline committen maar is 4 uur downtime rekenen veel of weinig? iemand hier nog een idee over.

Dat met die alarmen klinkt simpel in te richten, zal hier me eens in verdiepen.

Het hangt gewoon erg van je storage af.. soms is het maken van een cloon sneller dan het comitten van snapshots (in geval de guest down kan).
Om te weten te komen hoe snel je storage is zou je eens een cloon kunnen maken van een online systeem naar dezelfde storage. Deze kan je gewoon cancelen wanneer dit teveel impact heeft of te lang duurt. Tijdens de 'kopie' kan je op je datastore zien hoe snel de data groeit en daar dus ook een beetje van kan afleiden hoe lang het gaat duren.

Voor als mensen deze post nog een keer lezen.

Het duurde bij mij offline 30 minuten om deze snapshots te verwijderen.

Dat is netjes..

Snelle storage of zit je op ondertussen ESX 4.1?

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

EVA 8400 en nog steeds 3.5