What are the benefits to activate this option in VSC : Perform VMware consistency snaphot

[#1]

Hi all,

In the Virtual Storage Console, this option is recommended but if I have a virtual machine with a lot of I/O. What is the best practice ? Can I desactivate this option without risk ?

[#2]

A consistency snapshot would be a best practice as it attempts to quiesce the filesystem so that the data is as consistent as possible. It does this by creating snapshots of the VM until i gets down to 16 Kb or below and does a final write out and deletes the snapshot. It's not 100% necessary to do but if you care about your backups I would highly recommend it.

[#3]

Actually I have to disagree with William. The VMware Snapshots only value is the VSS writer inside the Guest that makes an attempt at quiecing the file system as William described. However all modern OSes use a Journaled filesystem and very rarely is their any data sitting in the VM guest SCSI driver. IO normally flows from the guest SCSI driver and immediately into the vKernel IO stack. Therefore, in my opinion, the guest quiecing option provides little value in the way of consistency. Moreover the VMware snapshot process tends to be disruptive to the guest and can often lead to trapped or orphaned VMware snapshots. Again, in my opinion, you are placing the VM at greater risk by using this option than the risk of data loss of not using it. That is, I believe the odds of an outage of the VM or data loss in the VM due to using VMware snapshots is greater than the odds of data not being consistent during a NetApp snapshot. Moreover you can further improve these odds by taking more NetApp backups(snapshots) if you are not using the VMware snapshots.

I would save the VMware snapshot option strictly for certain VMs that perhaps need some sort of guest OS flush (not sure what those workloads would be though).

Unfortunately neither NetApp, nor VMware, nor Microsoft have an official stance on this so you are left to make the decsion on your own and listen to the advice (for whats it's worth) from folks like William and I.

Keith

[#4]

Excellent retort Keith and many valid points brought about. The only reason I would recommend the VM snapshots in this instance is the case of high I/O workloads and trying to protect block consistency more than the OS itself; this of course comes with overhead. As you correctly pointed out though NetApp will do a far better job of it than VMware does through abstraction layers thus if available the Snap* product line directly would be far superior.

[#5]

AH Yes...Good point William. Anything that is transactional or IO intensive should likely have a SnapManager to properly protect them. I should have mentioned that, thanks for keeping me honest there. Thats the thing, usually workloads need more than the VMware snapshot offers or they don't need that much...It's sort of a odd middle ground that hurts the backup speed and reliability...

[#6]

Many thanks for your help William and Keitha, I will try to analyze your answers and decide to implement the best solution regarding my VMs

[#7]

Hi all,

In fact, we have VMs with a lot of I/O and we note that the VMs freezes wen the option is activate.

1) One of these VMs are running with SQL 2000 on W2K3

2) Others are running with SQL 2008 with database mirroring.

In the first case the database can disappear and in the second case the database freezes and causes a failover.

Thanks for your help.

[#8]

Yes, This can happen. The VSS writer provided from VMware does a Freeze on SQL but it is rather ungraceful about it and disconnects or failovers are common. However youreally should have some sort of quiecing done on a VM like that. Have you looked at our SnapManager for SQL?

[#9]

Hi,

No at this time because the SQL Backups are made through SQL dumps.

[#10 · Accepted solution]

OK, Thats another whole issue. I really hope you are doing the DataDumps to a different volume. Doing SQL dumps to a volume then snapping it results in huge snapshots and it pointless (the data is still on the same disks). You are way better off just quiecing the DB and snapping the volume. Ideally with SMSQL or at least with the PrePost Script function of VSC, or a custom workflow in SnapCreator.

keith