VMware Cloud Community
Vinsane
Contributor
Contributor
Jump to solution

VM Snapshot Crashed VM, 50+ VM-0001-s0xx.vmdk now in File System??

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

Reply
0 Kudos
1 Solution

Accepted Solutions
a_p_
Leadership
Leadership
Jump to solution

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é

View solution in original post

Reply
0 Kudos
6 Replies
a_p_
Leadership
Leadership
Jump to solution

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é

Vinsane
Contributor
Contributor
Jump to solution

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. Smiley Happy

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.!

Reply
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

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é

Reply
0 Kudos
Vinsane
Contributor
Contributor
Jump to solution

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?

Reply
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

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é

87Marc
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos