I have a VM with 2 virtual drives attached (/Volumes/externalHDD/CentOS6.4_x64.vmwarevm/Virtual Disk.vmdk and /Users/user1/Desktop/extra3.vmdk ). As you can see the extra disk is outside of the VM itself. I made the mistake of making a backup copy of the VM by copying it to another external hard drive that had the same label (/Volumes/externalHDD/CentOS6.4_x64.vmwarevm). Over the last few months I have been working off the original VM, I made a number of snapshots and removed a couple snapshots.
Yesterday, I realized I had cleared off some logs from the VM that weren't captured in any snapshots I had on the main VM... So I thought, no problem, I have the backup. I unplugged the external hdd with the original vm, plugged in the backup HDD, fired up the VM, grabbed the files I needed, then shut it back down. No problems so far, everything came up happily. When I tried to start up the original VM, however, it failed to start, giving me this error in vmware.log:
Worker#1| I120: DISKLIB-CHAIN : "/Users/user1/Desktop/extra3.vmdk" : failed to open (The parent virtual disk has been modified does not match the corresponding parent content ID in the child (18).
At this point I realized that because I had taken the snapshots, and I now have a disk chain for extra3.vmdk inside /Volumes/externalHDD/CentOS6.4_x64.vmwarevm... Looks like there are 2 snapshots:
Before attempting to fix anything, I have backed up both VMs and extra3.vmdk to a 3rd external media. I then did some googling and came across these two pages:
I determined my chain is (from mac terminal: head -n 15 extra3xxxxx.vmdk):
|extra3.vmdk (60 GB)||extra3-000002.vmdk (130 MB)||extra3-000001.vmdk (1.7GB)|
RW 209715200 SPARSE "extra3.vmdk"
RW 209715200 SPARSE "extra3-000002.vmdk"
CID=5c11353b <<-- Not sure why this is the same as parent, as file is 1.7GB, but assume isn't an issue?
RW 209715200 SPARSE "extra3-000001.vmdk"
The parent / child CIDs match up between the snaps, but the base has has a different CID when compared the parentCID of it's first child (in red). I assume this is because some background process on the backup VM must have written to the disk when I started up the backup VM, thinking it had exclusive use of the base vmdk. awesome...
At this point I just want to get as much of the data from the 2 snapshots as I can... There are a bunch of new log files and a GIT repo I would really like to be able to recover from those delta snaps.
So, on the off change it might work, after backing everything up. I tried just changing the parentCID in extra3-000002.vmdk to fa8de35e. I used vim in mac terminal and pressed ctrl+c to keep entire monolithic vmdk from attempting to be loaded.
VM booted, cool! But when I tried to access the second HDD, not so happy.
[user1@localhost ~]$ cd /extra3
[user1@localhost extra3]$ ls -l
ls: reading directory .: Input/output error
[user1@localhost extra3]$ dmesg
EXT4-fs error (device sdb1): ext4_find_entry: reading direcotry _#2 offset 0
sd 2:0:1:0: [sdb] Unhandled sense code
sd 2:0:1:0: [sdb] Result: hostbyte=DID OK driverbyte=DRIVER_SENSE
sd 2:0:1:0: [sdb] Sense Key : Medium Error [current]
sd 2:0:1:0: [sdb] Add. Sense: Unrecovered read error
sd 2:0:1:0: [sdb] CDB Read(10): 28 00 00 01 29 08 00 00 00 08 00
So then I figured I could try to fix the filesystem...
[user1@localhost ~]$ sudo umount /extra3
[user1@localhost ~]$ fsck.ext4 -cDfty -C 0 /dev/sdb1
[user1@localhost ~]$ e2fsck /dev/sdb1 -y
[user1@localhost ~]$ sudo mkfs.ext4 -s /dev/sdb1
Didn't help much, "fixed" a bunch of bad blocks, connected most inodes to lost+found. I was able to get into the filesystem after that, but everything had been moved to /extra3/lost+found/_#XXXXXXX (where XXXXX is was the block number) some of them seemed to be files that I could access, but it looked like none of the data written to either of the snapshots was recovered.
Additional Setup Details:
MacBook Pro /w Fusion 5.0.0
CentOS 6.4 x64
Thanks a bunch in advance!