VMware Cloud Community
wimbor
Contributor
Contributor
Jump to solution

ESX Revert to snapshot for VM with disks on two datastores

Hi everybody,

Yesterday we had a problem when reverting to a snapshot. I just wanted to share my experience and check with you all of this is a (known) bug. Is a patch available?

We have a few VM's that have two virtual disks on separate datastores on our SAN (mainly for IO and different RAID requirements). These VM's were created by Virtual Center 2.0. When reverting to a snapshot on one of these VM's we had some strange behaviour. (Snapshot taken and reverted when the machine was shut down.)

VC would revert to the snapshot and show the task as completed, but the snapshot manager would still show the old snapshot. We thought this was strange, and when starting the VM we noticed something was very wrong. The VM now had still two disks, but both disks had the same contents. The Windows event log also indicated that it had reset the ID on the drive. Basically our VM had two links to the same virtual disk, still in its snapshot state....

When logging in on the console of ESX, we still could see the delta VMDK and snapshot files. We tried again to revert to the old snaphot using VC, and we also suspect more delta files were created. Finally we tried the vmware-cmd command to remove the snapshots, but although it reported to have delete the snapshot, nothing was removed.

This behaviour was very similar to what was reported on the forum earlier:

http://www.vmware.com/community/thread.jspa?messageID=533739

We probably ran into the same bug in VC and ended up with a rather uncomfortable situation.

In the end we used this procedure to revert to the original state:

\- remove VM from inventory

\- check VMDK for snapshot info (was clean)

\- emptied the .vmsd file

\- deleted the delta's

\- change the VMX to use the correct VMDK

\- add VM to inventory

We will now change the filenames of the disks on the datatores so that they are unique, as suggested in the other article.

QUESTION:

\- have others experienced this before?

\- is it fixed?

\- will changing the VMDK names fix this behaviour? (we do not want to screw up another live machine)

The real problem with this is that VC detemines the names of the virtual disks when creating the VM, so this behaviour cannot be avoided unless you manually create the VMDK's in advance and link them afterwards... Pretty lame for an otherwise great product as ESX...

Best Regards

Wim

Reply
0 Kudos
1 Solution

Accepted Solutions
Morpheus
Contributor
Contributor
Jump to solution

Hi all,

today I checked the workaround to rename one of the diskfiles to have unique names. Taking, reverting and deleting of snapshots works fine.

What I did:

1. Shutdown VM

2. Remove the two (or more) disks from config (via VC/GUI)

3. Rename the diskfiles to unique names (commandline)

vmkfstools -E

4. Add existing disks to config of VM (via VC/GUI)

5. Start VM

Hope this helps.

Best Regards,

Morpheus.

View solution in original post

Reply
0 Kudos
9 Replies
sebek
Enthusiast
Enthusiast
Jump to solution

What are the names of vmdk files? Are they identical?

Were are snapshot files stored after creation of the snap?

Reply
0 Kudos
wimbor
Contributor
Contributor
Jump to solution

Both VMDK's were created with VC and had indeed identical names, on different datastores.

A VMware KB also indicated this error (ID 5096672).

The snapshot files seem to be created on the first datastore for both VMDK's. Can the location be influenced?

Regards,

Wim

Reply
0 Kudos
sebek
Enthusiast
Enthusiast
Jump to solution

I have noticed, that ESX can produce garbage trying to write delta files for the files with the same names but located on different datastores.

Try to manually edit second vmdk file name and reconfigure you vm to point to new disk.

FYI

You can change snap location by changing "Working directory" entry under Options in VM settings.

Morpheus
Contributor
Contributor
Jump to solution

Hi everybody,

we have had the same problem this week.

One VM with two disk-files located on 2 different volumes (NAS) with the same filename (choosen by VC).

After snapshot and revert to snapshot, the configuration of the vm was wrong and we could not revert to the snapshot.

We fixed this the same way you did (unregister, manualy correct the vmx, etc.) and the vm is now up and running again.

we will check the workaround (renaming disk-files to unique names, create/revert snapshot) on thuesday/wednesday next week.

Best regards,

Morpheus.

Reply
0 Kudos
pcomo
Enthusiast
Enthusiast
Jump to solution

Hi,

It would seem that this problem is the same one that which it met with VCB when VM has 2 discs on of Datastore different.

And the workaround is that we need to rename the second disk with a unique name.

see this topic

http://www.vmware.com/community/message.jspa?messageID=658845

Reply
0 Kudos
Morpheus
Contributor
Contributor
Jump to solution

Hi all,

today I checked the workaround to rename one of the diskfiles to have unique names. Taking, reverting and deleting of snapshots works fine.

What I did:

1. Shutdown VM

2. Remove the two (or more) disks from config (via VC/GUI)

3. Rename the diskfiles to unique names (commandline)

vmkfstools -E

4. Add existing disks to config of VM (via VC/GUI)

5. Start VM

Hope this helps.

Best Regards,

Morpheus.

Reply
0 Kudos
wimbor
Contributor
Contributor
Jump to solution

Hi Morpheus,

Thanks a lot for sharing your test results! I did not get around testing the snapshot myself, although I did change to unique names already. At least we now know that our snapshots will be taken correctly in the future.

I left the question open because I would like some feedback from a VmWare employee as well. I really think this is something that should be fixed in VC, because VC created the disks with identical names in the first place.

Best Regards,

Wim

Reply
0 Kudos
enDemand
Enthusiast
Enthusiast
Jump to solution

Wimbor,

I know that you are leaving this open for a VMware employee, but I wanted to add my 2 cents. Smiley Happy The steps that Morpheus gave are correct and this is a confirmed bug with VMware...see the KB article on this at:

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=5096672

With that said, placing disks on different datastores is something that cannot be avoided sometimes, even if VMware recommends against it, due to varying RAID requirements, I/O separation, storage management policies, or simply not having enough room on the existing datastore to place the new VMDK. If you must place a VMDK on another datastore, then the best approach would be to create it using vmkfstools rather than using VC. This way you have full control over the naming of the file, among other things.

I am surprised this hasn't been fixed yet in the two patch updates for VC, since it impacts VCB as well for similarly configured VMs.

If you find this or any other answer useful, please consider awarding points by marking the answer "correct" or "helpful".
Reply
0 Kudos
wimbor
Contributor
Contributor
Jump to solution

Hi enDemand,

THanks for your comment and link to the bug descrition. Just like yourself I am also puzzled why this issue was not solved in VC yet. RAID config differences are the reason why we did the configuration on two datastores. And that is a fairly logical thing to do, so I would assume.

I leave the topic open for VmWare to comment. Smiley Happy

Best Regards,

Wim

Reply
0 Kudos