Snaphunter / Rvtools reporting differently?

[TB_Rich]

Hi,

Recently I have discovered using a NetApp SAN and NFS that we were experiencing snapshot removal issues, I have identified this to be the issue with not having prefvmx.consolidateDeleteNFSLocks = "TRUE" set. I have set this and its working great as it should.

But, I have setup snaphunter to report on snapshots so I can quickly see if any have failed to remove from SMVI - and nearly all my VM's are reporting to have snapshots, some as many as 60!!!

When I look at the VM's in the VI client however, they have no snapshots and the disk's being accessed are the proper vmdk's and not a snapshot of the disk like -000001.vmdk

Alarmed by this I installed Rvtools as a backup check and that is reporting no snapshots on the VM's - as the VM gui says.

My question then... is snaphunter just plain wrong! or is right on some level and is there corrective action to perform? We only retain a few days of snapshots (certainly not 60!) on the NetApp but this should be transparent to the VM and the base vmdk anyway I would have thought?

Many Thanks if anyone can shed some light and help clear this up for me.

Rich.

[dinny · Accepted solution]

Hiya,

All snaphunter does is look at the actual files that exist on your vmfs partitions.

If you want to check it - use putty on the ESX server to do an "ls" of the VM directory in question.

You can most likely use the datastore browser in the VI client to see the same files too.

The main advantage of snaphunter is that it just looks at the actual files, and does not rely on just reporting what VC thinks is happening re snap shots.

I've made a later version of snap_hunter with a little extra functionality - pm me with your email address and I'll send you a copy if you like.

Dinny

[TB_Rich]

Hi,

Yeah looking at the file's there are multiple snapshots, but I believe these are old and unsed. In fact if I actually paid attention to the email report I would have noticed that the snapshots snaphunter is reporting are under a directory called .snapshot which is where the netapp stores its snapshots. I think snaphunter is too cleaver in this respect! What I will therefore do is off the visibility to the .snapshot directory to make it invisible to the file level - should stop snaphunter from seeing them and reporting more than there are.

With respect to the snapshots being old. Am I correct in thinking I can delete these snapshots direct from the file system as the VM is using correctly using the base vmdk and not some name-000001.vmdk for example.

I'll send you my email over in a bit, many thanks.

Cheers,

Rich.

[dinny]

Hi Rich,

I've never used netapps - so I can't really comment on exactly how it uses snapshots.

I would guess that perhaps they are old and unused - but at the end of the day you need to be certain of that in your environment before you actually delete them.

All snap_hunter really is, is a tool to let you know what snapshot files exist on your file systems - only you (or someone familiar with your specific environment) can really be sure how any snapshots that it reports on actually got there, and following on from that, what the implications of removing them are.

Dinny

[TB_Rich]

They were caused by a 'bug' removing snapshot's from NFS datastores - I have the fix inplace now to stop the hanging when removing snapshots.

All I need to do now is update the last few machines to consolidate properly to a base vmdk and then delete the volume level snapshots from netapp which contain these bogus vm snapshots - which are the ones snap_hunter is seeing!

Thanks for your help - I really should read have read the email report more throughly tho!!

Rich