Onderwerp: Onmogelijk om VMWare image van OpenFiler weg te kopieren

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

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.

@pantsy, haha mooie reactie! Maar uiteraard
staat hij uit

Oorspronkelijk geplaatst door MortyDot

@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 ?

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.

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.

Oorspronkelijk geplaatst door Pantsy

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.

• 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?

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...

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.

Oorspronkelijk geplaatst door visser

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.

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!

Oorspronkelijk geplaatst door wila

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.

Oorspronkelijk geplaatst door wila

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.

Oorspronkelijk geplaatst door wila

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.

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.

Oorspronkelijk geplaatst door visser

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.

Oorspronkelijk geplaatst door visser

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.

Oorspronkelijk geplaatst door visser

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.