noetus
Contributor
Contributor

BIG problem with raw disk and snapshots - parent modified, cannot read disk

I am running Fusion 2.0 Beta 1 on a Macbook Pro. This problem is NOT specific to Fusion 2.0 I believe.

Some time ago I created a raw disk (using the vmware-rawdiskcreator tool) for all of my data, some 150GB worth. I used an NTFS partition on my MacBook Pro's hard drive as the raw disk. My OS for the VM was on a virtual drive. I have been using this happily for some time.

I recently decided to create a new VM with a slightly different OS setup and thought it would be straightforward to use the old raw disk partition with the new VM. What I did NOT realize is that for SOME unknown reason the old OS had created a whole slew of snapshots and child disk images. The RAW disk was not holding the most recent version of my data. What made this particularly hard to spot was that the raw disk .vmdk file is in a directory called 'Hard Disk Images', while all the child snapshots were inside the VM package itself, hidden from my view. The original disk was called MyDisk.vmdk, in the 'Hard Disk Images' folder. Inside the VM package I see now (too late) a file called 'MyDisk-000001.vmdk' and a whole bunch of other files (150 of them) thus: MyDisk-000001-s001.vmdk, MyDisk-000001-s002.vmdk, MyDisk-000001-s003.vmdk, all the way up to MyDisk-000001-s150.vmdk. Why the heck here are all these snapshots, I really don't know - I certainly never asked for them. I was under the impression that every time I shut down the old VM, my NTFS partition, now accessible from my Mac OS, would contain all of my data - just as it was accessible inside the VM. NO NO NO NO NO!!!!

BAD!! What has happened is that I added the lines into the new VM configuration file to mount the virtual disk MyDisk.vmdk. Then when I started the new VM, I was puzzled because it seemed like I was looking at a rather old version of my data partition. I powered down - note WITHOUT making any changes to the disk (no file deletions or additions) - and attempted to start the old VM. That's when I got this error message:

"Cannot open the disk '/Users/.vmwarevm/MyDisk-000001.vmdk' or one of the snapshot disks it depends on.

Reason: The parent virtual disk has been modified since the child was created."

Now my question is: how do I get my data back? I would also know WHY Fusion created all these child snapshots, WITHOUT me telling it to and not for any particular reason as far as I can tell.

I assume that the old VM has detected that the parent virtual disk has been mounted more recently than the last time it mounted it. I'm hoping that I can bypass this error message somehow and get my data back by virtue of the fact that I did not modify any of the data on the parent disk, I just looked at it using Windows Explorer.

Is that right? Can anyone take me through the steps? This is rather a serious issue for me!!

Thanks in advance.

Also, once I get my data back if I can, HOW do I ensure that Fusion never does this again - that every time the VM powers down the most recent version of my data is actually contained in the raw partition?

0 Kudos
11 Replies
WoodyZ
Immortal
Immortal

I hope you have backups of your data besides what was or was supposed to be on the RAW Disk otherwise you may be out of luck.

Also if you're going to use a RAW Disk you need to disable Snapshots and Suspend on the Virtual Machine using a RAW Disk. This is done by adding the following to the .vmx configuration file.

suspend.disabled = "TRUE"

And

snapshot.disabled = "TRUE"

I'm sorry that I can't tell you how to fix this within the confines of how Fusion manages this as I've not had the need to examine it so you'll have to wait until someone from VMware can comment on it or someone else that knows if its possible to fix.

I do know a way how to open up a snapshot .vmdk and extract the data out of it although it's a little convoluted however if you don't have backups its better then loosing your data.

I have used WinImage 8.10, which is a Windows App, running on OS X using X11 and Darwine. You could also run it from a Windows Virtual Machine and open then target .vmdk file(s) via a share as well. Just so you know I've done this with single Fusion snapshot files of a monolithic disk and have not tried it with split disks.

BTW JSYK Almost from the moment you booted the new Virtual Machine that you attached the RAW Disk to that was being used on the other Virtual Machine the hard drive was being modified even thought you think you didn't do anything other then look at it in Windows Explorer. There are many things happening in the OS that make modifications to a disk when booted that you obviously are unaware of.

noetus
Contributor
Contributor

Thanks for your response!

I do have a fairly recent backup so if I lose the disk all is not lost. But some recent modifications and additions would be, and it will be hard for me to track what those were.

I found a thread which appears might be able to help me make the modifications to the vmdk files with a hex editor that may allow me to recover the data:

http://communities.vmware.com/thread/94593?tstart=0&start=15

I'm hopeful that no modifications were made to the parent disk as there is no OS on it, it's purely a data disk. Once I mounted it within the VM using Disk Manager I had a quick look round with Explorer and then shut down the VM.

This might be jumping the gun a little bit, but if I get the disk up and running again it's still going to have 150 or so split virtual children disks. How can I force Fusion to flush the data to the raw parent disk and eliminate the virtual child disks?

Also, I'm curious: why does Fusion do this? My thought was that perhaps it happens when there is an unexpected shutdown.

0 Kudos
WoodyZ
Immortal
Immortal

I'm hopeful that no modifications were made to the parent disk as there is no OS on it, it's purely a data disk. Once I mounted it within the VM using Disk Manager I had a quick look round with Explorer and then shut down the VM.

What you do not seem to understand is it doesn't matter that their is not an OS on the RAW Disk. Once that RAW Disk was initialized under the new Virtual Machine you attached it to the disk was being modified! Even if all you did what boot the new Virtual Machine with it attached and shut it down the disk was modified. I don't have time to get into all the technical details and besides that it's not a Fusion issue in this respect as this has only to do with Windows.

This might be jumping the gun a little bit, but if I get the disk up and running again it's still going to have 150 or so split virtual children disks. How can I force Fusion to flush the data to the raw parent disk and eliminate the virtual child disks?

Also, I'm curious: why does Fusion do this? My thought was that perhaps it happens when there is an unexpected shutdown.

You have not presented enough information to address this issue at this point in time. Recover you data first and then we can attempt to address this.

0 Kudos
noetus
Contributor
Contributor

I understand what you're saying about modifying the disk even when it's a data disk only.

The recovery attempt appears to have worked. I copied all of the .vmdk files to a new location (there are 152 of them) and pointed the parent CID of the main child file to the CID of the base disk which itself indexes the raw partition. I then changed the configuration file of the new second VM to point to the main child file and booted up and all seems to be well. This is all without touching any of the original vmdk files. I ran chkdsk and it found 5 unindexed files and some minor related errors but I don't know whether this is related to the issue at hand or not. The data appears to be the latest version.

Perhaps I got lucky here. In any case, I appear to be ready to move on to the second part of the problem - how to flush out the child slices. Here's what I have:

MyDisk-000001-s001.vmdk

MyDisk-000001-s002.vmdk

MyDisk-000001-s003.vmdk

.

.

.

MyDisk-000001-s149.vmdk

MyDisk-000001-s150.vmdk

MyDisk-000001.vmdk

MyDisk-pt.vmdk

MyDisk.vmdk

The first 150 slices comprise about 3GB altogether and the raw disk is around 150GB as I said.

How do I reduce all of this so I just have:

MyDisk-pt.vmdk

MyDisk.vmdk

and all that 3GB of data is flushed out to the raw disk? When the VM is powered down 'Discard snapshot' is greyed out.

0 Kudos
noetus
Contributor
Contributor

I attempted to use diskCreate with -C option to clone the disk but that didn't seem to work - it returned a lot of errors about disk or file access denied.

0 Kudos
noetus
Contributor
Contributor

OK, so this has happened AGAIN.

This time, snapshot.disabled = "TRUE" is in the .vmx file. IT MADE NO DIFFERENCE AT ALL. I now have a child snapshot with 150 slices inside the VM package, where it is completely hidden from me, and this is DANGEROUS because I keep copies of my old VMs as backups, and if I go back to a backup by copying across an older package and virtual disk copy (which I keep separately) I can LOSE all the recent changes in my data disk as the VM goes back to an older version of that disk - even though I haven't asked it to!

WHY DOES FUSION DO THIS?????? And more to the point, how can I STOP it from doing this? That was my question earlier - still not answered Smiley Sad

0 Kudos
WoodyZ
Immortal
Immortal

Again, I'm sorry I do not have an answer for this issue however I have to ask...

In your OP you said, "I am running Fusion 2.0 Beta 1 on a Macbook Pro. This problem is NOT specific to Fusion 2.0 I believe" so I have two questions.

Why are you using Beta Software in either a Production Environment or in a scenario that could/would cause an unacceptable loss? This certainly is not considered to be a Best Practice!

Are you saying this has happened in Fusion 1.x with the parameter snapshot.disabled = "TRUE" in the target Virtual Machine's .vmx configuration file?

FWIW I'm running RAW Disks in Fusion 1.x and have not had this problem (yet) and I believe you may be the only User to report such a situation when the parameter was set in the .vmx file.

I hope someone from VMware is going to chime in here because this is a serious situation in any respect if the parameter snapshot.disabled = "TRUE" in the target Virtual Machine's .vmx configuration file is set!

0 Kudos
RDPetruska
Leadership
Leadership

This time, snapshot.disabled = "TRUE" is in the .vmx file. IT MADE NO DIFFERENCE AT ALL.

Did you edit the vmx file while the guest was shut down, powered off, and NOT open within Fusion at all? If the guest was open in Fusion, or suspended, or running, then the edits would typically be overwritten.

0 Kudos
noetus
Contributor
Contributor

I don't believe so. I confirmed afterwards that snapshot.disabled = "TRUE" was still in the .vmx file, and it was.

0 Kudos
jim_gill
Expert
Expert

There was an update deep in the code that unintentionally deactivated the "snapshot.disabled = true" line in the vmx file. I don't have Fusion 2.0 Beta 1 installed right now, and don't recall if this shipped as an undetected bug in that beta, but I recently checked in the fix for that bug for the next beta. If the bug got out into the wild, my apologies. We do take steps to prevent a snapshot from being taken against a virtual machine that uses raw disk partitions.

One thing you can do now is add the additional line

ide0.0.deviceType = "rawDisk"

to the config file. That should shut snapshots off again, and make you safer. My fix just does it automatically.

noetus
Contributor
Contributor

Thanks for this. Very helpful. I'll add that to the vmx file and report back if there any further problems.

0 Kudos