We appear to have a corrupted .img file on one of our VMs. The repository this .img is on is an iSCSI LUN, however we are unable to restore this LUN from snapshot due to a SAN error.
Fortunately, we export all SAN LUNs to another SAN each night, so we have an exact copy of the problem LUN on this backup SAN.
But it's a different SAN - and I'm guessing that the LUN will to all intense purposes be identical to the existing presented repository that contains the corrupt .img file.
Is it going to be possible to 'read' this restored LUN in the pool is there is an existing LUN / Repository running duplicate?
What's the best way to restore this .img file?
Is it as simple as using iscsiadmn to manually mount the restored LUN from the backup SAN, and then copy the .img file over to the live repository in /OVS/
Any suggestions anyone?
We have this LUN in which is our (hopefully) clean repository - however whatever we do we are unable to mount the LUN on either the VM Hosts, or a VM manager.
We simply want to mount this OCFS2 formatted LUN on any system so that we can copy a file off.
OK we have managed to get one of our VM hosts to connect to the backup SAN and finally now it can list the restored LUN out in 'Physical Disks'.
So the disk is there
However - amazingly, we STILL can't get at anything on the disk - it may as well be blank.
We are just trying to present a restored LUN to a server - how on earth can this be so insanely difficult?!!?!?
All sorted in the end.
If any of you are interested - the magic of debugfs.ocfs2 saved the day.
First task is to convert your SAN snapshot into a fully provisioned volume - that shouldn't be too hard.
Next, you need to get this disk visible to an OVM host. You don't need to view it as a repository, if you are recovering from an existing / running repository, it's most likely that you won't be able to mount this anyway.
Once the disk was visible to an OVM host - I was then able to do:
Once in, I can browse inside the OCFS2 disk - and find the file I need to restore - noting the inode:
1445143 3528 36 1 0004fb000012000042b3b371ed9931a2.img
Then it's just a matter of dumping out the file - ideally with the same name / destination of the VirtualDisk you need to restore (assuming you noted this filename down before you deleted it!)
dump -p <1445143> /OVS/Repositories/0004fb000003000048ab690158532eba/VirtualDisks/0004fb000012000042b3b371ed9931a2.img
Then it's just a matter of waiting for the dump to complete.
..and that's how to recover a single VM from a LUN snapshot.
Edited by: Jeff_J on 29-Jan-2013 00:45