PDA

Bekijk Volledige Versie : Onmogelijk om VMWare image van OpenFiler weg te kopieren



MortyDot
24/04/12, 22:52
Goeie avond iedereen.

Ik heb de volgende situatie:
1VMware vps image en overige files.
Deze zijn opgeslagen en draaiende vanaf een OpenFiler server.
Echter krijg ik een fout als ik de files probeer te kopiëren van de OpenFiler-NAS naar een lokale schijf op de VMWare machine waar deze vps-server op draait.
Als ik in OpenFiler zelf probeer de file te tar'en krijg ik een error.
Als ik de map probeer weg te kopiëren krijg ik een error.

-------------------------------------------------------------------
[root@storage1 vmware-storage1]# tar -cf vmware-storage1/
tar: Cowardly refusing to create an empty archive
Try `tar --help' or `tar --usage' for more information.
[root@storage1 vmware-storage1]# tar -cf vmware-storage1/*
tar: vmware-storage1/vmware-storage1/vps244 - Davical/vps244 - Davical-flat.vmdk: File shrank by 4773163008 bytes; padding with zeros
tar: Error exit delayed from previous errors
[root@storage1 vmware-storage1]# dir
vmware-storage1
[root@storage1 vmware-storage1]# mv vmware-storage1/ /mnt/backup/backup/
mv: reading `vmware-storage1/vmware-storage1/vps244 - Davical/vps244 - Davical-flat.vmdk': Input/output error
-------------------------------------------------------------------

Ik wil de files kopiëren naar een andere disk.
Hebben jullie een suggesties?

Met vriendelijke groeten,
Sven

Pantsy
25/04/12, 01:51
Staat de vm aan of uit? Dat kan ik niet helemaal opmaken uit je bovenstaande situatie, een vm kopieren/inpakken die live is dat is een no-go namelijk.

MortyDot
25/04/12, 10:55
@pantsy, haha mooie reactie! Maar uiteraard
staat hij uit ;)

visser
25/04/12, 11:17
@pantsy, haha mooie reactie! Maar uiteraard
staat hij uit ;)

Ik denk dat gewoon één van de files in het vmware image inderdaad niet gelezen kan worden.
Ga even in de vmware vps244 directory, en cat de files één voor één naar /dev/null , gewoon om te zien welke kapot is.
Zie je met dmesg bv ook error meldingen van de harddisks ?

Pantsy
25/04/12, 14:46
Je weet het maar immers nooit =) Het is of een file welke nog locked is door vmware (een ander process zou ietwat raar zijn) of een bestand is inderdaad corrupt. Wat visser aangeeft kan, maar er word al aangegeven welke file er problemen geeft en dat is je vdisk. Kan je de vm nog wel opstarten? Lijkt toch als of er een lock op zit namelijk door de vmware host.

Spyder01
25/04/12, 15:09
De files cat-ten naar /dev/null is een optie inderdaad, mijn ervaringen in die zin met OpenFiler zijn niet positief om het in een productieomgeving als storage voor VM's te gebruiken. Locked files en corruptie is in dit geval in ieder geval de oorzaak van niets met dat image kunnen doen. Hardware falen ansich zou kunnen, maar die kans acht ik wel het minst groot.

Je kunt de files ook even stuk voor stuk kopiëren naar /dev/null, maar of je cp't of cat' dat moet je zelf weten :) Misschien valt de schade mee.

visser
25/04/12, 16:04
Je weet het maar immers nooit =) Het is of een file welke nog locked is door vmware (een ander process zou ietwat raar zijn) of een bestand is inderdaad corrupt. Wat visser aangeeft kan, maar er word al aangegeven welke file er problemen geeft en dat is je vdisk. Kan je de vm nog wel opstarten? Lijkt toch als of er een lock op zit namelijk door de vmware host.

Ah, ja, de file staat al in de posting, had ik overheen gekeken.
Maar kan, en gebruikt, vmware zodanige locks dat een ander (root) proces zelfs de file niet kan lezen ?
Hm, een filer waarbij het filer OS meekijkt op een iSCSI partitie is natuurlijk qua locking een rare situatie.
Kan dat uberhaupt wel, vraag ik me af, als onafhankelijke kernel meekijken op een 'lokaal' FS wat door een andere kernel in gebruik is ?

Een advisory lock, of nog beperkter, een filename.lock file in de directory waarmee het proces een kopie van zichzelf bewust maakt dat de zaak al in gebruik is, houden een ander proces, zeker een root proces natuurlijk niet weg van de file.

Ook locking over netwerk FS'en (nfs, cifs) heeft een een hoop mitsen en maren; Over iSCSI verwacht je wel alle semantiek die het gebruikte filesystem normaal heeft.

MortyDot
25/04/12, 17:07
Hij gaat inderdaad bij de vmdk op zijn snuffert.
# CP werkt ook niet.
VMstart wel op
Wegkopieren van andere VM's gaf geen problemen



Is er ook een manier om de file individueel te cheken op fouten/repareren?

systemdeveloper
25/04/12, 17:29
Het zal wel aan mij liggen, maar heb je niet gewoon een zooitje van je tar gemaakt?

[root@storage1 vmware-storage1]# tar -cf vmware-storage1/

-> Proberen 'niks' te tarren met een directorynaam als tar-target...

[root@storage1 vmware-storage1]# tar -cf vmware-storage1/*

-> Vernielen van je bestanden door alles in je vmware-storage1/* te gebruiken als tar-target. (Met een beetje mazzel alleen het eerste bestand)

[root@storage1 vmware-storage1]# dir
vmware-storage1

-> Een vmware-storage1 dir/file in je vmware-storage1/ directory... dat wilde je vast niet?

[root@storage1 vmware-storage1]# mv vmware-storage1/ /mnt/backup/backup/
mv: reading `vmware-storage1/vmware-storage1/vps244 - Davical/vps244 - Davical-flat.vmdk': Input/output error

-> Proberen een lege tar (want dat bestand lijkt nullified te zijn door de tar error) te moven...

wila
26/04/12, 05:48
Wat SystemDeveloper zegt dus, al weet ik niet zeker ofdat tarren zonder input inderdaad de target overschrijft. Het scenario met de wildcard kan dat inderdaad gedaan hebben (Sorry ik ben te lui om het te gaan testen)

Als je VM echter nog opstart, dan is er waarschijnlijk nog een mogelijkheid om deze nog te klonen naar een andere disk vanuit het guestOS zelf. Kwestie van een extra disk toevoegen op het volume waar je naartoe wilt kopieren en dan de zaak kopieren. Als het stuk waar je host OS een defect ziet niet door je guestOS wordt opgevraagd, dan heb je zelfs een goede kopie.
Is wellicht te proberen waard. Afhankelijk van je guest OS zijn daar verschillende methodes voor.

Oh en Pantsy.. je kan wel een live VM wegkopieren. Maar dat vereist een truukje en levert dan natuurlijk een crash consistent VM op. Dit is niet altijd wenselijk, maar voor veel VM's "goed genoeg".
1. Kopieer de vmx/vmxf/nvram bestanden
2. Neem een snapshot van je disks, dit sluit je base disks netjes af en zet die bestanden in read only mode
3. Kopieer alleen de base disks, de delta's/redo disks kunnen niet gekopieerd worden want die bestanden zijn open in read/write mode. Gebruik hiervoor het vmkfstools programma op de ESX host (of onder ESXi het vmkfstools.pl script van je VMA/vCLI)
4. Commit je snapshots

Dit is zo'n beetje hoe dat de VMware backup programma's werken. Er is inmiddels nog wat extra mogelijk dankzij de Changed Block tracking API, maar het bovenstaande is de basis.

wila
26/04/12, 06:04
Ah, ja, de file staat al in de posting, had ik overheen gekeken.
Maar kan, en gebruikt, vmware zodanige locks dat een ander (root) proces zelfs de file niet kan lezen ?
Hm, een filer waarbij het filer OS meekijkt op een iSCSI partitie is natuurlijk qua locking een rare situatie.
Kan dat uberhaupt wel, vraag ik me af, als onafhankelijke kernel meekijken op een 'lokaal' FS wat door een andere kernel in gebruik is ?

Een advisory lock, of nog beperkter, een filename.lock file in de directory waarmee het proces een kopie van zichzelf bewust maakt dat de zaak al in gebruik is, houden een ander proces, zeker een root proces natuurlijk niet weg van de file.

Ook locking over netwerk FS'en (nfs, cifs) heeft een een hoop mitsen en maren; Over iSCSI verwacht je wel alle semantiek die het gebruikte filesystem normaal heeft.
Ik geloof niet dat TS iSCSI gebruikt (of kijk ik nu ergens overheen) het kan net zo goed NFS zijn. Als het iSCSI is dan zie je op openfiler niet meer dan een partitie daar je ESX host er het VMFS filesysteem op plaatst.

In principe kan je de disks kopieren als VMware ze open heeft als read/write, maar de kans is gewoon groot dat er naartoe is geschreven terwijl je die xx GB aan het kopieren bent en dan is je kopie dus corrupt.
Het is mij niet duidelijk of TS de kopies maakt vanuit zijn openfiler console of vanaf een ESX/ESXi host.
Als het het laatste was, dan had hij zondermeer vmkfstools moeten gebruiken ipv het cp commando, omdat vmkfstools de disks net iets anders cloned en anders omgaat met je host zijn resources. Met een cp kunnen je disks gefragmenteerd worden, zijn er geen zaken mogelijk zoals een thin disk copy of eager zero disk copy en kan je host wel eens unresponsive worden tijdens de kopie.

wila
26/04/12, 07:08
Mocht je guestOS linux zijn, dan kan je bijvoorbeeld het volgende doen:

Download een image van systemrescuecd.
Zorg dat je VM opstart vanaf de iso die je hebt gedownload
Voeg een extra disk toe aan je VM die precies even groot is als je origineel
Boot je VM van de "CD"
Je kan dan bijvoorbeeld met dd je disk kopieren. ervan uitgaande dat /dev/sda je origineel is en /dev/sdb je kopie (Controleer dat met fdisk -l !!!!)

dd bs=512 if=/dev/sda of=/dev/sdb conv=noerror,sync

eventueel zou je ook ddrescue kunnen gebruiken.
http://www.cgsecurity.org/wiki/Damaged_Hard_Disk

Of je kan in je VM booten en rsync gebruiken.
Er zijn vele manieren om je data te redden (of om die alsnog te vernielen als je niet precies weet wat je aan het doen bent)
Zonder technische details is het lastig om een goed advies te geven anders dan "laat het een expert doen".
De vraag is natuurlijk hoeveel de data waard is.

Success!

visser
26/04/12, 21:09
Ik geloof niet dat TS iSCSI gebruikt (of kijk ik nu ergens overheen) het kan net zo goed NFS zijn. Als het iSCSI is dan zie je op openfiler niet meer dan een partitie daar je ESX host er het VMFS filesysteem op plaatst.


Dat is wat ik me afvroeg; TS kan in elk geval met het Openfiler-OS in de directory/drive/partitie kijken die door zijn vmware server gemount wordt. (dwz: uit zijn prompts meen ik op te maken dat hij in het Openfiler OS zit).

Ik ken Openfiler niet voldoende om te weten of dat automatisch betekend dat die via een netwerk FS (NFS,CIFS) geëxporteerd wordt, of dat zoiets ook nog kan als de export via iSCSI gaat.
Met twee hosts kijken naar eenzelfde block device zou wel een risicovolle of anderszins rare situatie zijn, en ik betwijfel of het kan werken.
Dus een export via een netwerk FS lijkt dan het meest logisch.

Maar dan is dus de vraag of wanneer een client computer via NFS een file locked, of dat dan als resultaat kan hebben dat het OS op de NFS server een I/O error krijgt bij het lezen ervan.
En trouwens of VMware uberhaupt gebruik maakt van file locks (of alleen een lock-file ).
NFS locking is lastig onderwerp, en iemand als DJB kan er lang over ranten.



In principe kan je de disks kopieren als VMware ze open heeft als read/write, maar de kans is gewoon groot dat er naartoe is geschreven terwijl je die xx GB aan het kopieren bent en dan is je kopie dus corrupt.


Ja, maar alleen qua interne filestructuur. Niet corrupt als in "geeft I/O error" lijkt me.



Het is mij niet duidelijk of TS de kopies maakt vanuit zijn openfiler console of vanaf een ESX/ESXi host.
Als het het laatste was, dan had hij zondermeer vmkfstools moeten gebruiken ipv het cp commando, omdat vmkfstools de disks net iets anders cloned en anders omgaat met je host zijn resources. Met een cp kunnen je disks gefragmenteerd worden, zijn er geen zaken mogelijk zoals een thin disk copy of eager zero disk copy en kan je host wel eens unresponsive worden tijdens de kopie.

Uit de prompt root@storage1 , en de poging (eerst) een tar te maken had ik opgemaakt dat hij in het OS van z'n fileserver bezig was.
TS zou nog met 'dmesg' (of gewoon in de diverse /var/log/ files) kunnen kijken of er bij het optreden van die I/O error ook fouten door het VFS gemeld worden voor de onderliggende drives.

Pantsy
26/04/12, 22:30
Clonen is een optie om er erg simpel vanaf te zijn, dan hangt het er alleen vanaf of de TS over deze functie beschikt (ivm licenses).

@wila als ik erg simpel terug mag antwoorden, zulke problemen heb je niet met betaalde software en dan heb je zulke methodes niet nodig (gelukkig). Het kan voor in nood scenario's wel helpen, wellicht in dit geval.

wila
27/04/12, 06:20
Dat is wat ik me afvroeg; TS kan in elk geval met het Openfiler-OS in de directory/drive/partitie kijken die door zijn vmware server gemount wordt. (dwz: uit zijn prompts meen ik op te maken dat hij in het Openfiler OS zit).
Dat kan alleen voor een NFS export. Dit omdat bij gebruik van iSCSI er automatisch het VMFS filesysteem op komt te staan.
Voor VMFS is geen ondersteunde filesystem driver beschikbaar op het moment omdat VMFS een gesloten filesysteem is. Er is een reverse engineered driver beschikbaar, maar die gebruik je normaalgesproken alleen als het echt moet en dat niet vermelden in een topic lijkt me een grote misser.

Met twee hosts kijken naar eenzelfde block device zou wel een risicovolle of anderszins rare situatie zijn, en ik betwijfel of het kan werken.We dwalen af van het topic, maar ja dat kan. VMFS is een cluster filesysteem. Het is zelfs een benodigdheid om een live vMotion te kunnen doen. Er staan natuurlijk nooit 2 dezelfde bestanden als write open op 2 hosts. Hier wordt eveneens de snaphot technologie toegepast.

Ja, maar alleen qua interne filestructuur. Niet corrupt als in "geeft I/O error" lijkt me.
Inderdaad. Een I/O error wijst op een onderliggend probleem en is iets wat je al helemaal niet wil zien en je tip aan TS om in de logs te gaan kijken waar dat vandaan komt is goed advies.

wila
27/04/12, 06:27
Clonen is een optie om er erg simpel vanaf te zijn, dan hangt het er alleen vanaf of de TS over deze functie beschikt (ivm licenses).Hoe is dit een licentie issue als je het origineel toch wist?


@wila als ik erg simpel terug mag antwoorden, zulke problemen heb je niet met betaalde software en dan heb je zulke methodes niet nodig (gelukkig). Het kan voor in nood scenario's wel helpen, wellicht in dit geval.
Ik snap je "betaalde software" referentie niet. De vmkfstools tool waar ik naar refereer is onderdeel van VMware commerciele software. Kennis van zaken bij noodsituaties zal je beter helpen dan "betaalde magische software" want je moet nog steeds op de juiste knopjes drukken en over genoeg kennis beschikken.

Anyways.. op de situatie die TS schetste was je opmerking "files open kan niet kopieren" correct voor die situatie. Het klonk alleen alsof je daarmee ook wilde zeggen dat het technisch niet kan. Ik gaf alleen een voorbeeld van hoe het toch mogelijk is.

Pantsy
27/04/12, 13:44
@wila, jij begrijpt mij wel gezien je vmware expertise, je kan standaard niet clonen met bepaalde licentie vormen (of geen licentie vorm beter gezegd) met vmware. Technisch kan je zeker uit de voeten, maar zonder de juiste kennis of gebruik van de tools lijkt het mij niet verstandig om dit iemand te laten uitvoeren (vmware of binnen het os zelf).

Daarnaast levert vmware zulke dergelijke geautomatiseerde en nette tools om dit uit te voeren wat uiteraard ideaal is voor in een situatie zoals deze, het kost alleen wel geld om deze functies te mogen gebruiken. Dat je ook kennis nodig hebt om op knopjes te drukken ben ik met je eens, alleen laten we wel eerlijk wezen dat dit een stuk gemakkelijker is dan het iemand via cli te laten doen, iets waar vmware ook naar streeft en duidelijk te merken is in vmware 5.

@mortydot, installeer 2 nieuwe nodes met vmware + een vcenter vm en cloon de vm, je hebt standaard 60 dagen trial om de mogelijkheden van vmware uit te proberen, of de optie van wila om alles 1 op 1 te copyen naar een nieuwe vdisk. Misschien ben je er inmiddels al uit?

crossplatform
29/04/12, 10:24
Is het een optie om?:

- met Redobackup een backup te maken van de VM
- nieuwe VM aanmaken met dezelfde specs
- Restore uitvoeren met Redobackup

(of een andere backup solution zoals Acronis mag ook, uiteraard)

wila
29/04/12, 17:21
@Crossplatform TS is hier al in geen week meer geweest, dus ik gok dat het probleem of is opgelost OF dat het niet zo'n belangrijke VM was. Is verder een goeie tip hoor.

@Pantsy Ah OK, ja dan zou je een versie kunnen aanschaffen of inderdaad in probeer modus. Zelf zat ik te denk aan het gebruik van VMware converter (https://my.vmware.com/web/vmware/info/slug/infrastructure_operations_management/vmware_vcenter_converter_standalone/5_0), ook nog steeds gratis dacht ik. Maar omdat TS niet meer reageerd had ik niks verder aan te raden. Je kan converter namelijk op meerdere manieren inzetten en het ligt ook een beetje aan zijn gebruikte product en guestOS. Veranderingen maken binnenin de VM (software installeren voor te klonen e.d.) is echter af te raden. In principe zal een kopie binnenin de VM meer kans van slagen hebben als een op vSphere host niveau.
Niet omdat er dan geen blanko stukken in de disk vallen, maar omdat een host kopie gewoon helemaal lukt of helemaal niet. En met I/O errors erbij wordt dat dan de laatste versie.

wila
04/05/12, 16:45
Maar kan, en gebruikt, vmware zodanige locks dat een ander (root) proces zelfs de file niet kan lezen ?
Hm, een filer waarbij het filer OS meekijkt op een iSCSI partitie is natuurlijk qua locking een rare situatie.
Kan dat uberhaupt wel, vraag ik me af, als onafhankelijke kernel meekijken op een 'lokaal' FS wat door een andere kernel in gebruik is ?

Omdat je duidelijk geinteresseerd blijkt te zijn in het technische verhaal qua locking mechanisme, hier een linkje naar een interessant artikel hierover: VMFS Locking Uncovered (http://blogs.vmware.com/vsphere/2012/05/vmfs-locking-uncovered.html)

visser
04/05/12, 18:15
Omdat je duidelijk geinteresseerd blijkt te zijn in het technische verhaal qua locking mechanisme, hier een linkje naar een interessant artikel hierover: VMFS Locking Uncovered (http://blogs.vmware.com/vsphere/2012/05/vmfs-locking-uncovered.html)

Dank, inderdaad een boeiende link (en rondje web vanaf daar) over vmfs locking (en primitieven zoals scsi reservations).

MortyDot
11/05/12, 21:46
Iedereen bedankt voor de reacties en de vele mogelijkheden.
Ik moet wel zeggen dat ik de meest creatieve en tijdsintensieve dingen gelezen heb hier :-)

Ik heb het uiteindelijk opgelost door de vmware-client met een extra disk (deze disk staat op de lokale vmware-server) te booten.
De inhoud van de originele disk te kopiëren naar de nieuwe disk.
Vervolgens oude disk verwijderen vanuit de vmware-host.
Nog wat laatste instellingen met boot-cd-tools.

Keuze hiervoor is gevallen omdat het een relatief kleine schijf waarbij de waarde van de inhoud ook geen 'werkdagen' aan waarde had.
Iedereen bedankt voor de reacties! Heb er zeker wat mee kunnen doen.
Alvast een goed weekend :-)