Hi,
I have installed VMware Workstation 6.0 and created a VM which is housing Windows XPPro and installed various pieces of software that I needed making a couple snapshots along the way. Yesterday I booted my machine and tried to make a clone of one the snapshot. It did not let me do that and now whenever I try to start the VM I get the following error message:
"Unable to open file C:\VMWareFiles\WinXP-BaseDisk2.0000001.vmdk. One of the disks in this virtual machine is already in use by a virtual machine or by a snapshot".
I have searched this forum without finding any answers to my problems thus this posting. Can anyone help on this issue?
Many thanks in advance
Abdel
How can renaming vmdk's be dangerous? All that changes is the pointer to the virtual disk on the VM. You are dealing with exactly the same disk, exactly the same virtual machine, exactly the same virtual hardware.
Next you are going to tell me you can't change the location of where a vmdk file is created 'cause it's dangerous? So you can't paste it to another place?
Or maybe you'll try to tell me you can't change the disks that a VM has after you've first run it?
That's all totally untrue. All that you do by copying/renaming a vmdk file and only a vmdk file is preventing your old VM from running with a pointer to an unexisting location (old filename/location of vmdk) UNTIL you point it to the new filename/location.
It's literally the same as creating a new VM with a different disk that is not locked down.
And for the record, you are the one that suggested deleting files in the first place. All I'm saying is that if you really want to delete them rather than renaming them/changing their location then do it to the recycle bin. Anyone that read that without the intention of criticizing and with an IQ higher than 30 would have realized that:
a) If you can't do as I said and send something to the recycle bin, then don't do it at all, because you would be doing something that you were not told to do.
b) That I was NOT talking about the vmdk files which, because it's impossible to have a VMDK file of a OS partition that occupies less than 2gb (limit for recycle bin btw).
My advices are a lot sounder and safer than what you were suggesting, 'deleting the right files'.
Think a bit will you? Right before you create a VM all you have is a VMDK file at most. Does VMware care where that file is if a VM hasn't even been created at all? No. So why can't you rename/make a copy of an existing VMDK file and either create a new VM to accommodate your new VMDK or change the settings on the disk of the old VM so that it points to the new VMDK? Hell if you want to be even more safe... though I don't think that who started this thread is such a noob that he's need me to go this far... just COPY the vmdk, create a NEW VM and that way, nothing will be effectively changed. The old VMDK, VM and all other files that link it to it's state will still be there, and you will then have a new VM with a copy of your original VMDK to play with!
Anyway thanks for letting me know that every time I answer on a post you are likely to answer as well I have to enumerate all little steps, make full paragraphs about how and why it will work, think about the unthinkable and basically make it idiot proof.
cogumel0
EDIT:
>>Yes - explorer will say this file is too large for the trashbin - so it will be deleted right away ... end of adventure
No, explorer will say this file is too large for the recycle bin and then ASK if you want to delete this file without going to the recycle bin OR if you wish to CANCEL. So unless you have never used a computer before in your whole life, or you have a serious problem with following instructions, you can never screw up. Get the facts straight.
Message was edited by:
cogumel0
>>> Anyway thanks for letting me know that every time I answer on a post you are likely to answer as well ...
This is just because I look into almost all disk related issues that are not solved after some posts.
I'd like to continue discussing disk-issues with you - let me suggest you at least read
http://sanbarrow.com/vmdk.html
to get an idea of the problems that you overlook at the moment
Ulli
sorry again if you felt offended
Seriously, it's not about whether I feel offended or not, which to be honest I don't. But something I noticed on some forums and that you strongly see on this one is that:
1) You try to get to the bottom of the problem, which is fine, but without first considering the basics. You (and when I say you I don't mean you alone) are too concentrated on what VMware is doing to the files and forget how windows interacts with the files as well for example. You ask for logs and logs and forget that sometimes the answer is just around the corner and does not need logs to be looked at. Sometimes you need to step back and work at the problem from another angle.
2) People seem to think that the knowledge of people on forums is measured by the quantity of posts they have in total. Yesterday I posted a solution on another post and then had 3 users that had more posts than me posting EXACTLY the same thing as me. So did they decide that since I had less than 5 posts at the time whatever I had said was not even worth reading?
In this case though, I think he's more interested in getting this to work right now than finding out why it happens. Sure, at a later stage, after he gets this working, he might be interested in finding out why this worked and the real solution rather than a workaround. Though it's been what, 2 days without his VM working and just posting logs?
And the way you replied to my posts suggested, to me, that you didn't even take a minute to read what I really wrote and totally dismissed my suggestions probably on account of the number of posts I have.
The way I thought about this was: If a VM says a VMDK is already in use, and because this already happened to me, easiest thing to happen, and probably more likely, is that one of VMware's processes has it locked down. So let's find out exactly what is locking it down, if anything. It's a lot easier to check this before checking the other files of this VM, have to open logs, post logs and maybe delete something which, as you said it yourself, might ruin the VM if you don't delete the right ones.
I'm not denying your knowledge about VMware and I'm sure you know more than me, though it's just that sometimes you need to step back, go back to the basics, and if that fails work at the problem from a different angle.
Anyway I'd love to continuing discussing VMDK's with you.
cogumel0
Fine - you are really interested.
cogumeIO - I believe this case is much simpler / trickier - after a reboot there can be no lock on vmdk or vmx files which would be valid from VMware-site of things.
Thats why checking the presence of lockfiles is enough.
In 99% percent of cases simply deleting the lockfiles/dirs helps.
There may be some really strange thing going on inside the vmsd file - that could be another reason why VMware messages a locked file.
Oliver has started looking into it - lets wait for results
Oliver is working on a solution, I reckon it would be good if in the meantime we could provide a workaround.
Obviously I didn't expect people to always use my workarounds as if they were solutions. It's still something that needs to be looked at. But that's probably for people from VMware to look at, not me. Specially in this case which, by what Oliver said I'm assuming is a bug with snapshots.
Anyway, out of curiosity, can you tell me something:
When running a VM with a VMDK are the changes kept on the VMDK or on the VMX? I'm assuming it's on the VMDK, but I might be wrong. I don't really use VMDK's on my machines a lot so hadn't had the change to test that.
cogumel0
Next you are going to tell me you can't change the location of where a vmdk file is created 'cause it's dangerous? So you can't paste it to another place?
FYI: Moving and renaming a vmdk CAN be dangerous - depending on other circumstances (linked clone, pathname bug, workdir set, ...)
Oliver is working on a solution, I reckon it would be good if in the meantime we could provide a workaround.
My solution only will be a workaround... and as far as I can see this is the only possible workaround.
And yes it is snapshot related and seems to be a bug.
When running a VM with a VMDK are the changes kept on the VMDK or on the VMX?
It depends. Changes to the disk are kept in the VMDK, changes to the VM config (virtual HW) are kept in the VMX.
Changes to the disk "structure" (snapshots) are kept in both (and the VMSD).
Ok, granted it can be dangerous to rename the original VMDK under some[/b] circumstances (though I've never had any problems with that). But it will never be dangerous to copy it 'cause even if something is damaged, it will obviously be only the copy, not the original one.
I personally do that all the time and never had any problems with it. Granted, I use a different method, but still never had problems with it. And if all changes to the disk are kept on the VMDK using his method, that's one more reason for him to try using a copy of his original VMDK I'd say.
Seriously if he has space in his physical HDD to copy all the VMDK's from that machine (and notice I've dropped the renaming) I don't see why he shouldn't try it. He certainly has nothing to lose.
cogumel0
(though I've never had any problems with that)
You really must be a lucky guy.
It can even be dangerous to copy a VMDK / VM!
Ever heard of the absolute pathname bug? If not take a search on the forums.
In this case copying the VMDKs doesn't help anyway.
Since he has snapshots it will prevent him from commiting / reverting them (at least without manual intervention) or maybe even destroy the disks (see above).
Copying VMDKs can be a resolution if you don't have snapshots or don't care about them.
But even in this case you have to take some precautions to prevent possible corruption of the original VMDK.
I think I have a resolution to the problem - but I need the contents of the VMSD (and most likely the VMX too).
Ho Orreh,
I am the person who originally raised this issue and I am sorry I have not replied to your postings as I have been away for a few days.
I am still at loss understanding what needs to be done to resolve this issue. You say it is a bug. Where Can I information on this? Is is on VMWare list?
Anyway this is the contents of my vmx file:
config.version = "8"
virtualHW.version = "6"
numvcpus = "2"
scsi0.present = "TRUE"
memsize = "1024"
ide0:0.present = "TRUE"
ide0:0.fileName = "WinXP-BaseDisk1-000004.vmdk"
ide1:0.present = "TRUE"
ide1:0.fileName = "auto detect"
ide1:0.deviceType = "cdrom-raw"
floppy0.autodetect = "TRUE"
ethernet0.present = "TRUE"
ethernet0.connectionType = "nat"
ethernet0.wakeOnPcktRcv = "FALSE"
usb.present = "TRUE"
ehci.present = "TRUE"
sound.present = "TRUE"
sound.fileName = "-1"
sound.autodetect = "TRUE"
svga.autodetect = "TRUE"
pciBridge0.present = "TRUE"
mks.keyboardFilter = "allow"
displayName = "WinXP-Base"
guestOS = "winxppro"
nvram = "Windows XP Professional.nvram"
deploymentPlatform = "windows"
virtualHW.productCompatibility = "hosted"
tools.upgrade.policy = "useGlobal"
ide0:1.present = "TRUE"
ide0:1.fileName = "WinXP-BaseDisk2-000004.vmdk"
ide1:0.autodetect = "TRUE"
floppy0.startConnected = "FALSE"
floppy0.fileName = "A:"
isolation.tools.hgfs.disable = "TRUE"
ethernet0.addressType = "generated"
uuid.location = "56 4d a7 a0 3d 39 42 44-d7 ed fa 40 06 38 4e 24"
uuid.bios = "56 4d a7 a0 3d 39 42 44-d7 ed fa 40 06 38 4e 24"
ide0:0.redo = ""
ide0:1.redo = ""
pciBridge0.pciSlotNumber = "17"
scsi0.pciSlotNumber = "16"
ethernet0.pciSlotNumber = "32"
sound.pciSlotNumber = "33"
ehci.pciSlotNumber = "34"
ethernet0.generatedAddress = "00:0c:29:38:4e:24"
ethernet0.generatedAddressOffset = "0"
tools.remindInstall = "FALSE"
ide1:0.startConnected = "TRUE"
tools.syncTime = "FALSE"
and this is the contents of my vmsd file:
snapshot.lastUID = "2"
snapshot.numSnapshots = "2"
snapshot.current = "2"
snapshot0.uid = "1"
snapshot0.filename = "Windows XP Professional-Snapshot1.vmsn"
snapshot0.displayName = "WinXP-Base"
snapshot0.description = "Base VM with Windows XP SP2"
snapshot0.type = "1"
snapshot0.createTimeHigh = "276554"
snapshot0.createTimeLow = "-1235269280"
snapshot0.numDisks = "2"
snapshot0.disk0.fileName = "WinXP-BaseDisk1.vmdk"
snapshot0.disk0.node = "ide0:0"
snapshot0.disk1.fileName = "WinXP-BaseDisk2-000001.vmdk"
snapshot0.disk1.node = "ide0:1"
snapshot.mru0.uid = "2"
snapshot1.uid = "2"
snapshot1.filename = "Windows XP Professional-Snapshot2.vmsn"
snapshot1.parent = "1"
snapshot1.displayName = "WinXP-Base+Software"
snapshot1.description = "Windows XP Pro SP2 Base Operationg System with Developers Development Software, and Active PDF Server"
snapshot1.type = "1"
snapshot1.createTimeHigh = "276575"
snapshot1.createTimeLow = "273108800"
snapshot1.numDisks = "2"
snapshot1.disk0.fileName = "WinXP-BaseDisk1-000001.vmdk"
snapshot1.disk0.node = "ide0:0"
snapshot1.disk1.fileName = "WinXP-BaseDisk2-000001.vmdk"
snapshot1.disk1.node = "ide0:1"
snapshot.mru1.uid = "1"
Your help and time is very much appreciated.
Thanks
I am the person who originally raised this issue and I am sorry I have not replied to your postings as I have been away for a few days.
No problem
I am still at loss understanding what needs to be done to resolve this issue. You say it is a bug.
I assume it is a bug (the probability is at 99.9%).
Where Can I information on this? Is is on VMWare list?
Not that I'm aware of (it seems we just discovered it).
On to your problem:
You have four snapshots in the VM directory, but only two of them are referenced in the VMSD file (though your VMX files references the fourth snapshot).
We first need to recover the snapshot tree.
Download the following ZIP http://sanbarrow.com/diskreport/tools.zip
extract it and copy vmreport.exe into the VM folder.
Then execute vmreport.exe and post the the contents of the newly generated vmreport.txt.
Ho Oreeh,
Basically I have only two snapshots but when I tried to clone one of the snapshots I started having this problem. I guess the other files are due to the fact that I have tried to revert to the last snapshot from where I was to enable the VM to start and on each occasion the vm started properly. The problem starts when you try to restart the VM. May be this explains it.
Anyway this is the result of the report:
VM report created 8/11/2007 8:32 UTC
OS: WinXP/.Net MSWin32
##############################
\### directory contents of C:/VMWareFiles
##############################
Date (modified) | Size | Permissions | Filename
-
----
Fri Jul 13 19:04:00 2007 | 1175618 | rwxrwxrwx |vmreport.exe
Tue Sep 11 09:32:58 2007 | 0 | rw-rw-rw- |vmreport.txt
Wed Sep 5 16:19:44 2007 | 48094 | rw-rw-rw- |vmware-0.log
Thu Aug 23 19:13:37 2007 | 51845 | rw-rw-rw- |vmware-1.log
Thu Aug 23 17:15:54 2007 | 71857 | rw-rw-rw- |vmware-2.log
Wed Sep 5 18:18:33 2007 | 46962 | rw-rw-rw- |vmware.log
Wed Aug 22 15:41:27 2007 | 1073741824 | rw-rw-rw- |Windows XP Professional-Snapshot1.vmem
Wed Aug 22 15:41:27 2007 | 18985821 | rw-rw-rw- |Windows XP Professional-Snapshot1.vmsn
Thu Aug 23 15:58:03 2007 | 1073741824 | rw-rw-rw- |Windows XP Professional-Snapshot2.vmem
Thu Aug 23 15:58:03 2007 | 18986691 | rw-rw-rw- |Windows XP Professional-Snapshot2.vmsn
Wed Sep 5 18:18:32 2007 | 8684 | rw-rw-rw- |Windows XP Professional.nvram
Thu Aug 23 17:24:39 2007 | 1201 | rw-rw-rw- |Windows XP Professional.vmsd
Fri Sep 7 10:19:46 2007 | 1643 | rw-rw-rw- |Windows XP Professional.vmx
Mon Aug 20 15:09:44 2007 | 278 | rw-rw-rw- |Windows XP Professional.vmxf
Thu Aug 23 15:52:57 2007 | 12489523200 | rw-rw-rw- |WinXP-BaseDisk1-000001.vmdk
Thu Aug 23 17:25:26 2007 | 340197376 | rw-rw-rw- |WinXP-BaseDisk1-000002.vmdk
Wed Sep 5 18:09:49 2007 | 1505624064 | rw-rw-rw- |WinXP-BaseDisk1-000003.vmdk
Tue Sep 11 08:30:25 2007 | 30343168 | rw-rw-rw- |WinXP-BaseDisk1-000004.vmdk
Wed Aug 22 15:37:04 2007 | 2055340032 | rw-rw-rw- |WinXP-BaseDisk1.vmdk
Thu Aug 23 17:25:26 2007 | 2686976 | rw-rw-rw- |WinXP-BaseDisk2-000001.vmdk
Thu Aug 23 17:15:52 2007 | 2686976 | rw-rw-rw- |WinXP-BaseDisk2-000002.vmdk
Wed Sep 5 18:09:49 2007 | 173998080 | rw-rw-rw- |WinXP-BaseDisk2-000003.vmdk
Tue Sep 11 08:30:25 2007 | 2686976 | rw-rw-rw- |WinXP-BaseDisk2-000004.vmdk
Wed Aug 22 15:37:04 2007 | 2752512 | rw-rw-rw- |WinXP-BaseDisk2.vmdk
##############################
\### vmxfile Windows XP Professional.vmx
\### Created: Mon Aug 20 14:07:08 2007
\### Modified: Fri Sep 7 09:19:46 2007
##############################
config.version = "8"
virtualHW.version = "6"
numvcpus = "2"
scsi0.present = "TRUE"
memsize = "1024"
ide0:0.present = "TRUE"
ide0:0.fileName = "WinXP-BaseDisk1-000004.vmdk"
ide1:0.present = "TRUE"
ide1:0.fileName = "auto detect"
ide1:0.deviceType = "cdrom-raw"
floppy0.autodetect = "TRUE"
ethernet0.present = "TRUE"
ethernet0.connectionType = "nat"
ethernet0.wakeOnPcktRcv = "FALSE"
usb.present = "TRUE"
ehci.present = "TRUE"
sound.present = "TRUE"
sound.fileName = "-1"
sound.autodetect = "TRUE"
svga.autodetect = "TRUE"
pciBridge0.present = "TRUE"
mks.keyboardFilter = "allow"
displayName = "WinXP-Base"
guestOS = "winxppro"
nvram = "Windows XP Professional.nvram"
deploymentPlatform = "windows"
virtualHW.productCompatibility = "hosted"
tools.upgrade.policy = "useGlobal"
ide0:1.present = "TRUE"
ide0:1.fileName = "WinXP-BaseDisk2-000004.vmdk"
ide1:0.autodetect = "TRUE"
floppy0.startConnected = "FALSE"
floppy0.fileName = "A:"
isolation.tools.hgfs.disable = "TRUE"
ethernet0.addressType = "generated"
uuid.location = "56 4d a7 a0 3d 39 42 44-d7 ed fa 40 06 38 4e 24"
uuid.bios = "56 4d a7 a0 3d 39 42 44-d7 ed fa 40 06 38 4e 24"
ide0:0.redo = ""
ide0:1.redo = ""
pciBridge0.pciSlotNumber = "17"
scsi0.pciSlotNumber = "16"
ethernet0.pciSlotNumber = "32"
sound.pciSlotNumber = "33"
ehci.pciSlotNumber = "34"
ethernet0.generatedAddress = "00:0c:29:38:4e:24"
ethernet0.generatedAddressOffset = "0"
tools.remindInstall = "FALSE"
ide1:0.startConnected = "TRUE"
tools.syncTime = "FALSE"
checkpoint.vmState.readOnly = "FALSE"
fileSearchPath = "C:\VMWareFiles;."
checkpoint.vmState = ""
fileSearchPath is set! This VM is NOT portable!
##############################
\### WinXP-BaseDisk1.vmdk
##############################
\# Disk DescriptorFile
version=1
CID=8fe818e7
parentCID=ffffffff
createType="monolithicSparse"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk1.vmdk"
\# The Disk Data Base
#DDB
ddb.virtualHWVersion = "6"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.adapterType = "ide"
ddb.toolsVersion = "7238"
##############################
\### WinXP-BaseDisk2.vmdk
##############################
\# Disk DescriptorFile
version=1
CID=dc415fe1
parentCID=ffffffff
createType="monolithicSparse"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk2.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
ddb.adapterType = "ide"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "16383"
ddb.virtualHWVersion = "6"
The following problems where detected:
- Extent WinXP-BaseDisk1.vmdk has wrong size! Expected size: 21474836480 - Actual size: 2055340032
If this is a sparse disk you can ignore this warning
- Extent WinXP-BaseDisk2.vmdk has wrong size! Expected size: 21474836480 - Actual size: 2752512
If this is a sparse disk you can ignore this warning
##############################
\### WinXP-BaseDisk1-000001.vmdk
##############################
\# Disk DescriptorFile
version=1
CID=d553c46d
parentCID=8fe818e7
createType="monolithicSparse"
parentFileNameHint="WinXP-BaseDisk1.vmdk"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk1-000001.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
The following problems where detected:
- Extent WinXP-BaseDisk1-000001.vmdk has wrong size! Expected size: 21474836480 - Actual size: 12489523200
If this is a sparse disk you can ignore this warning
##############################
\### WinXP-BaseDisk1-000002.vmdk
##############################
\# Disk DescriptorFile
version=1
CID=8888c18a
parentCID=d553c46d
createType="monolithicSparse"
parentFileNameHint="WinXP-BaseDisk1-000001.vmdk"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk1-000002.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
The following problems where detected:
- Extent WinXP-BaseDisk1-000002.vmdk has wrong size! Expected size: 21474836480 - Actual size: 340197376
If this is a sparse disk you can ignore this warning
##############################
\### WinXP-BaseDisk1-000003.vmdk
##############################
\# Disk DescriptorFile
version=1
CID=536a2771
parentCID=d553c46d
createType="monolithicSparse"
parentFileNameHint="WinXP-BaseDisk1-000001.vmdk"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk1-000003.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
The following problems where detected:
- Extent WinXP-BaseDisk1-000003.vmdk has wrong size! Expected size: 21474836480 - Actual size: 1505624064
If this is a sparse disk you can ignore this warning
##############################
\### WinXP-BaseDisk1-000004.vmdk
##############################
\# Disk DescriptorFile
version=1
CID=ad188735
parentCID=d553c46d
createType="monolithicSparse"
parentFileNameHint="WinXP-BaseDisk1-000001.vmdk"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk1-000004.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
The following problems where detected:
- Extent WinXP-BaseDisk1-000004.vmdk has wrong size! Expected size: 21474836480 - Actual size: 30343168
If this is a sparse disk you can ignore this warning
##############################
\### WinXP-BaseDisk2-000001.vmdk
##############################
\# Disk DescriptorFile
version=1
CID=dc415fe1
parentCID=dc415fe1
createType="monolithicSparse"
parentFileNameHint="WinXP-BaseDisk2.vmdk"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk2-000001.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
The following problems where detected:
- Extent WinXP-BaseDisk2-000001.vmdk has wrong size! Expected size: 21474836480 - Actual size: 2686976
If this is a sparse disk you can ignore this warning
##############################
\### WinXP-BaseDisk2-000002.vmdk
##############################
\# Disk DescriptorFile
version=1
CID=dc415fe1
parentCID=dc415fe1
createType="monolithicSparse"
parentFileNameHint="WinXP-BaseDisk2-000001.vmdk"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk2-000002.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
The following problems where detected:
- Extent WinXP-BaseDisk2-000002.vmdk has wrong size! Expected size: 21474836480 - Actual size: 2686976
If this is a sparse disk you can ignore this warning
##############################
\### WinXP-BaseDisk2-000003.vmdk
##############################
\# Disk DescriptorFile
version=1
CID=a95c8ae8
parentCID=dc415fe1
createType="monolithicSparse"
parentFileNameHint="WinXP-BaseDisk2-000001.vmdk"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk2-000003.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
The following problems where detected:
- Extent WinXP-BaseDisk2-000003.vmdk has wrong size! Expected size: 21474836480 - Actual size: 173998080
If this is a sparse disk you can ignore this warning
##############################
\### WinXP-BaseDisk2-000004.vmdk
##############################
\# Disk DescriptorFile
version=1
CID=dc415fe1
parentCID=dc415fe1
createType="monolithicSparse"
parentFileNameHint="WinXP-BaseDisk2-000001.vmdk"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk2-000004.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
The following problems where detected:
- Extent WinXP-BaseDisk2-000004.vmdk has wrong size! Expected size: 21474836480 - Actual size: 2686976
If this is a sparse disk you can ignore this warning
##############################
\### logfile vmware.log
##############################
Sep 05 18:10:21.828: vmx| Log for VMware Workstation pid=5088 version=6.0.0 build=build-45731 option=Release
Sep 05 18:10:24.750: vmx| DISK: OPEN ide0:0 'C:\VMWareFiles\WinXP-BaseDisk1-000004.vmdk' persistent R\[(null)]
Sep 05 18:10:25.109: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk1-000004.vmdk" (0xa)
Sep 05 18:10:25.109: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk1-000004.vmdk' (0xa): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:25.265: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk1-000001.vmdk" (0xe)
Sep 05 18:10:25.281: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk1-000001.vmdk' (0xe): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:25.437: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk1.vmdk" (0xe)
Sep 05 18:10:25.437: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk1.vmdk' (0xe): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:25.437: vmx| DISKLIB-LIB : Opened "C:\VMWareFiles\WinXP-BaseDisk1-000004.vmdk" (flags 0xa). 1C76114
Sep 05 18:10:25.437: vmx| DISK: OPEN 'C:\VMWareFiles\WinXP-BaseDisk1-000004.vmdk' Geo (16383/16/63) BIOS Geo (2610/255/63) freeSpace=114366Mb, ide
Sep 05 18:10:25.453: vmx| DISK: OPEN ide0:1 'C:\VMWareFiles\WinXP-BaseDisk2-000004.vmdk' persistent R\[(null)]
Sep 05 18:10:25.843: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk2-000004.vmdk" (0xa)
Sep 05 18:10:25.843: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk2-000004.vmdk' (0xa): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:26.000: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk2-000001.vmdk" (0xe)
Sep 05 18:10:26.000: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk2-000001.vmdk' (0xe): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:26.125: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk2.vmdk" (0xe)
Sep 05 18:10:26.125: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk2.vmdk' (0xe): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:26.140: vmx| DISKLIB-LIB : Opened "C:\VMWareFiles\WinXP-BaseDisk2-000004.vmdk" (flags 0xa). 1E4A444
Sep 05 18:10:26.140: vmx| DISK: OPEN 'C:\VMWareFiles\WinXP-BaseDisk2-000004.vmdk' Geo (16383/16/63) BIOS Geo (0/0/0) freeSpace=114366Mb, ide
Sep 05 18:10:26.171: vmx| DISKUTIL: ide0:0 : capacity=41943040
Sep 05 18:10:26.171: vmx| DISKUTIL: ide0:1 : capacity=41943040
Sep 05 18:10:26.171: vmx| DISKUTIL: ide0:1 : toolsVersion = 7238
Sep 05 18:10:26.171: vmx| DISKUTIL: ide0:0 : toolsVersion = 7238
Sep 05 18:10:46.109: vmx| VMX_PowerOn: ModuleTable_PowerOn = 1
Sep 05 18:10:49.531: vcpu-1| DISKUTIL: ide0:1 : toolsVersion = 7238
Sep 05 18:10:49.531: vcpu-1| DISKUTIL: ide0:0 : toolsVersion = 7238
Sep 05 18:10:54.062: vcpu-0| DISKUTIL: ide0:1 : toolsVersion = 7238
Sep 05 18:10:54.062: vcpu-0| DISKUTIL: ide0:0 : toolsVersion = 7238
Sep 05 18:11:10.578: vcpu-1| DISKUTIL: ide0:1 : toolsVersion = 7238
Sep 05 18:11:10.578: vcpu-1| DISKUTIL: ide0:0 : toolsVersion = 7238
Sep 05 18:11:32.562: vcpu-0| DISKUTIL: ide0:1 : toolsVersion = 7238
Sep 05 18:11:32.562: vcpu-0| DISKUTIL: ide0:0 : toolsVersion = 7238
##############################
\### VMDKs mentioned in vmware.log
##############################
Sep 05 18:10:22.515: vmx| DICT ide0:0.fileName = WinXP-BaseDisk1-000004.vmdk
Sep 05 18:10:22.531: vmx| DICT ide0:1.fileName = WinXP-BaseDisk2-000004.vmdk
Sep 05 18:10:24.750: vmx| DISK: OPEN ide0:0 'C:\VMWareFiles\WinXP-BaseDisk1-000004.vmdk' persistent R\[(null)]
Sep 05 18:10:25.109: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk1-000004.vmdk" (0xa)
Sep 05 18:10:25.109: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk1-000004.vmdk' (0xa): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:25.265: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk1-000001.vmdk" (0xe)
Sep 05 18:10:25.281: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk1-000001.vmdk' (0xe): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:25.437: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk1.vmdk" (0xe)
Sep 05 18:10:25.437: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk1.vmdk' (0xe): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:25.437: vmx| DISKLIB-LIB : Opened "C:\VMWareFiles\WinXP-BaseDisk1-000004.vmdk" (flags 0xa). 1C76114
Sep 05 18:10:25.437: vmx| DISK: OPEN 'C:\VMWareFiles\WinXP-BaseDisk1-000004.vmdk' Geo (16383/16/63) BIOS Geo (2610/255/63) freeSpace=114366Mb, ide
Sep 05 18:10:25.453: vmx| DISK: OPEN ide0:1 'C:\VMWareFiles\WinXP-BaseDisk2-000004.vmdk' persistent R\[(null)]
Sep 05 18:10:25.843: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk2-000004.vmdk" (0xa)
Sep 05 18:10:25.843: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk2-000004.vmdk' (0xa): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:26.000: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk2-000001.vmdk" (0xe)
Sep 05 18:10:26.000: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk2-000001.vmdk' (0xe): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:26.125: vmx| DISKLIB-DSCPTR: Opened : "WinXP-BaseDisk2.vmdk" (0xe)
Sep 05 18:10:26.125: vmx| DISKLIB-LINK : Opened 'C:\VMWareFiles\WinXP-BaseDisk2.vmdk' (0xe): monolithicSparse, 41943040 sectors / 20480 Mb.
Sep 05 18:10:26.140: vmx| DISKLIB-LIB : Opened "C:\VMWareFiles\WinXP-BaseDisk2-000004.vmdk" (flags 0xa). 1E4A444
Sep 05 18:10:26.140: vmx| DISK: OPEN 'C:\VMWareFiles\WinXP-BaseDisk2-000004.vmdk' Geo (16383/16/63) BIOS Geo (0/0/0) freeSpace=114366Mb, ide
##############################
\### disk descriptor tables
##############################
Filename | CID | pCID | createType | parentFileNameHint
-
----
WinXP-BaseDisk1.vmdk | 8fe818e7 | ffffffff | monolithicSparse | -none-
WinXP-BaseDisk2.vmdk | dc415fe1 | ffffffff | monolithicSparse | -none-
WinXP-BaseDisk1-000001.vmdk | d553c46d | 8fe818e7 | monolithicSparse | WinXP-BaseDisk1.vmdk
WinXP-BaseDisk1-000002.vmdk | 8888c18a | d553c46d | monolithicSparse | WinXP-BaseDisk1-000001.vmdk
WinXP-BaseDisk1-000003.vmdk | 536a2771 | d553c46d | monolithicSparse | WinXP-BaseDisk1-000001.vmdk
WinXP-BaseDisk1-000004.vmdk | ad188735 | d553c46d | monolithicSparse | WinXP-BaseDisk1-000001.vmdk
WinXP-BaseDisk2-000001.vmdk | dc415fe1 | dc415fe1 | monolithicSparse | WinXP-BaseDisk2.vmdk
WinXP-BaseDisk2-000002.vmdk | dc415fe1 | dc415fe1 | monolithicSparse | WinXP-BaseDisk2-000001.vmdk
WinXP-BaseDisk2-000003.vmdk | a95c8ae8 | dc415fe1 | monolithicSparse | WinXP-BaseDisk2-000001.vmdk
WinXP-BaseDisk2-000004.vmdk | dc415fe1 | dc415fe1 | monolithicSparse | WinXP-BaseDisk2-000001.vmdk
##############################
\### CID chain(s) according to vmdks
##############################
8fe818e7 - -> d553c46d -> 8888c18a -> 536a2771 -> ad188735
dc415fe1 - -> a95c8ae8
\### END OF REPORT ###
Now this explains a bit...
Your snapshot tree is this
WinXP-BaseDisk1.vmdk --- WinXP-BaseDisk1-000001.vmdk --- WinXP-BaseDisk1-000002.vmdk
\ | |
\ | WinXP-BaseDisk1-000003.vmdk
\ |
WinXP-BaseDisk1-000004.vmdk
WinXP-BaseDisk2.vmdk --- WinXP-BaseDisk2-000001.vmdk --- WinXP-BaseDisk2-000002.vmdk
\ | |
\ | WinXP-BaseDisk2-000003.vmdk
\ |
WinXP-BaseDisk2-000004.vmdk
but unfortunately the CID chain doesn't reflect this.
We can repair it.
Are you sure that you don't need the snapshots #3 and #4 anymore?
Hi Oreeh,
Thanks for the prompt reply. I only need the first snapshots as they are the most important one as they contain all of the settings for my work.
Let me know how to proceed and will do as soon as possible.
Thanks
OK, then we ignore snapshots #3 and #4
Then copy ddtget.exe and ddtset.exe (from the extracted ZIP) to the VM folder and execute the following commands in a command shell.
ddtget.exe -vmdk=WinXP-BaseDisk2-000001.vmdk -desc=WinXP-BaseDisk2-000001.txt
ddtget.exe -vmdk=WinXP-BaseDisk2-000002.vmdk -desc=WinXP-BaseDisk2-000002.txt
This creates two new files (WinXP-BaseDisk2-000001.txt and WinXP-BaseDisk2-000002.txt).
Open them in Wordpad and modify them according to the following
WinXP-BaseDisk2-000001.txt
\# Disk DescriptorFile
version=1
CID=fc415fe1
parentCID=dc415fe1
createType="monolithicSparse"
parentFileNameHint="WinXP-BaseDisk2.vmdk"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk2-000001.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
WinXP-BaseDisk2-000002.txt
\# Disk DescriptorFile
version=1
CID=fc415fe2
parentCID=fc415fe1
createType="monolithicSparse"
parentFileNameHint="WinXP-BaseDisk2-000001.vmdk"
\# Extent description
RW 41943040 SPARSE "WinXP-BaseDisk2-000002.vmdk"
\# The Disk Data Base
#DDB
ddb.toolsVersion = "7238"
Now execute the following commands in a command shell (you do have a backup - do you?):
ddtset.exe -vmdk=WinXP-BaseDisk2-000001.vmdk -desc=WinXP-BaseDisk2-000001.txt
ddtset.exe -vmdk=WinXP-BaseDisk2-000002.vmdk -desc=WinXP-BaseDisk2-000002.txt
Then open the VMX file in an editor and replace the following lines
ide0:0.fileName = "WinXP-BaseDisk1-000004.vmdk"
ide0:1.fileName = "WinXP-BaseDisk2-000004.vmdk"
with
ide0:0.fileName = "WinXP-BaseDisk1-000002.vmdk"
ide0:1.fileName = "WinXP-BaseDisk2-000002.vmdk"
Now we have to repair the VMSD file.
To do this I need to know the following:
When you created the VM, did you create it with 2 disks or did you add the second disk later?
If the latter: did you add the second disk while the first disk already had a snapshot?
If you are unsure we better ignore the ability to commit/revert the snapshots and simply recover the data from them![/b]
Message was edited by:
oreeh
Hi Oliver,
To answer your questions: One thing I remember was that I created the VM with two disks but when I booted the VM I could only see one disk. I had then to format the second disk. I think that I probably created the two snapshots before setting the second disk but I am not 100% sure.
My original intention was to have 2 disks one for the operating system and all software I need and the other one for the data. By the way how do you get the VM set with tow or more disks from the start and working properly?
Should I progress now with your instructions or wait for new instructions given my reply?
Thanks
Oliver,
One more thing. The two snapshots definitely relate to data held on the first disk only.
Thanks
By the way how do you get the VM set with tow or more disks from the start and working properly?
Simply add a second disk before powering on the VM for the first time.
Should I progress now with your instructions or wait for new instructions given my reply?
Yes, do as noted above.
After that move the following files out of the VM directory (since you are not 100% sure):
Windows XP Professional-Snapshot1.vmem
Windows XP Professional-Snapshot2.vmem
Windows XP Professional-Snapshot1.vmsn
Windows XP Professional-Snapshot2.vmsn
Windows XP Professional.vmsd
This will prevent you from committing/removing the snapshots but their content is still there!
Then remove the VM from inventory and re-add it.
After that try to power-on the VM and if WS doesn't complain anymore power it off immediately and report back.
Message was edited by:
oreeh
Since you tried some things before posting here the disks probably have some logical errors!
Depending on the WS behavior with the modified CIDs we may need to access them from outside the VM first.
According to the timestamps we should try to repair the CIDs for both disks.
If we don't need one of them we can easily remove it afterwards.
Hi Oliver,
Everything you said worked and the VM powered on without any problems. After it started I immediately powered off.
So what is next?
Again many thanks for your help.
Regards