Hi,
Hit a significant problem this morning and I haven't found much information available on the web.
I took a snapshot of a VM call it "WIN-APPSERVER" and it completely blew up the VM, the snapshot failed with the error
An error occurred while taking a snapshot: msg.snapshot.error-CHECKPOINT.
An error occurred while saving the snapshot: msg.snapshot.error-CHECKPOINT
And completely powered off the VM, attempting to power off was a complete failure, it generated the following error
An error was received from the ESX host while powering on VM WIN-APPSERVER (171dde1d-ef89-4751-aba7-9905931d8edf).
Failed to start the virtual machine.
Module DiskEarly power on failed.
Cannot open the disk '/vmfs/volumes/53ac8324-6c2d4c6c-fb05-7845c4f7b900/Upload/Reme-Apps-000001.vmdk' or one of the snapshot disks it depends on.
The system cannot find the file specified
VMware ESX cannot find the virtual disk "/vmfs/volumes/53ac8324-6c2d4c6c-fb05-7845c4f7b900/Upload/Reme-Apps-000001.vmdk". Verify the path is valid and try again.
Since i've seen this before, what I had to do was edit the VM, remove the HDD attached, which was INVALID, and re-attached the correct VMDK that had the VM OS on it. Poof the VM booted fine.
The question are..
#1, why did this happen, how can I prevent, has anyone seen this?
#2, I'm looking at the file system beneath where the VM is located and it's created 50+ .VMDKs with the following format. This is the SECOND time this is happened to a VM during a snapshot, and I've yet to find a solution. It's not listing as "Consolidation" needed. Anyone know how to carefully and correctly clean up these VMDK's and why it created over 50+ of them?
/vmfs/volumes/53ac8324-6c2d4c6c-fb05-7845c4f7b900/Upload # ls -al total 139130888
drwxr-xr-x 1 root root 8400 Jul 10 13:03 .
drwxr-xr-t 1 root root 3920 Jul 8 14:37 ..
-rw------- 1 root root 6554112 Jul 10 03:01 Reme-Apps-000001-ctk.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s001.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s002.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s003.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s004.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s005.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s006.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s007.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s008.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s009.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s010.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s011.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s012.vmdk
-rw------- 1 root root 327680 Jul 10 03:01 Reme-Apps-000001-s013.vmdk
Both virtual disks don't seem to be created on the ESXi host. They both have a createType="twoGbMaxExtentSparse".
What you may do is to convert the virtual disks to a supported format using the vmkfstools command line utility. Make sure you have an up-to-date backup (just in case something doesn't work as expected), and also ensure you have sufficient free disk space on the datastore to clone the disks.
For how to convert see VMware KB: Unable to power on a virtual machine with mounted sparse disks. In addition to this, you may also consider to convert the disks from IDE to SCSI following the steps in VMware KB: Converting a virtual IDE disk to a virtual SCSI disk.
André
This usually happens if the original VM was created by a hosted product like VMware Workstation or Player, and have then been uploaded to an ESXi host without converting the virtual disk to a supported format. Please attach the Reme-Apps.vmdk (the small descriptor file) to a reply post to see what can be done to fix this.
André
Now that makes sense! I ended up converting this VM from Citrix Xenserver, I downloaded the .VHD, then used a 3rd party tool called WinImage to convert the VHD into a VMDK and imported into my VMware environment
I really hope something can be done, also, let me know what you think about all those .vmdk's it created in the file system.
Odly, this also happened on my vCenter box a while back, and from what I can re-call this was not converted it was built from a scratch Windows Server 2008 R2 ISO. I would certainly appreciate your insight!
Thanks so much a.p.!
Both virtual disks don't seem to be created on the ESXi host. They both have a createType="twoGbMaxExtentSparse".
What you may do is to convert the virtual disks to a supported format using the vmkfstools command line utility. Make sure you have an up-to-date backup (just in case something doesn't work as expected), and also ensure you have sufficient free disk space on the datastore to clone the disks.
For how to convert see VMware KB: Unable to power on a virtual machine with mounted sparse disks. In addition to this, you may also consider to convert the disks from IDE to SCSI following the steps in VMware KB: Converting a virtual IDE disk to a virtual SCSI disk.
André
Thanks so much, I will give this a try, now since Snapshots aren't working, and my backup solution is not working either (VEEAM) as it relies on snapshots. Are you saying that a backup in this case would be me cloning the VM, and I would choose "Do Not Customize" right so it's an exact replica that could be potentially powered on and replace the production VM in the event I blow it up?
Would these processes clear out those 50+ vmdk's or is that something I can safely do manually after the fact?
From what I understood you already changed the virtual disk in the VM's settings back from Reme-Apps-000001.vmdk to Reme-Apps.vmdk!? In this case the snapshot .vmdk files are obsolete and can safely be deleted.
Since an application which relies on snapshots cannot be used for backups, you'll need to do this manually, e.g. by exporting the VM as an OVF. However, since you are actually going to clone the virtual disk, the original .vmdk files won't get modified and you can always revert to them. So it's up to you to decide whether you want to backup the files.
André
Vinsane,
I have the identical issue you describe in the OP. Can you elaborate on what you did to get this VM to power on again?
I see the below, but I was hoping for more details as I'm fairly new to Administering VMWare.
Vinsane wrote:
Since i've seen this before, what I had to do was edit the VM, remove the HDD attached, which was INVALID, and re-attached the correct VMDK that had the VM OS on it. Poof the VM booted fine.
Thanks,
Marc