snapshot consolidation changes since vSphere 6.0

[mdiver]

Could anyone confirm the information that HW version >=11 (the one that came with ESX 6.0) is needed to leverage the new consolidation mechanism?
Cormac doesn't point that out in http://cormachogan.com/2016/01/06/snaps ... phere-6-0/ - but I heard it more than once so far.

We have a "monster" Exchange server VM at one customer that didn't really benefit from the host-upgrade regarding the snapshot commit after the daily backups (1-5min. on >30k IOPS storage system).
But HW version is still below 11. It is not the server though, one just simply walks in and upgrades the HW version...

Thanks,
Mike

[mdiver]

Nobody has any comment on that?

Regards,
Mike

[dellock6]

Hi Mike, sorry but I've not found any detailed information around in regards to the minimum needed hardware version, and the tests we did and that went into my blog post were all with new VMs, so with the default hardware version 11. As this is VMware technology, you may also post into Cormac post a comment and check with them.

[tsightler]

I'm not aware of any virtual HW version requirement. So you are seeing 1-5 minute stuns on this VM?

[mdiver]

Thanks Luca and Tom for your reply.
One of your collegues mentioned that VM HW version requierement to me recently. But I could not find any hints on that. The topic is already closed at Cormacs blog.

Fortunately, our stuns last only for a few seconds. The whole snapshot commit takes between 5-15min. - depending on if it was an active-full or an incremental run.
We can't use BfSS here, as it's a DataCore storage system.
It would have been the perfect system to test the new commit mechanism as we upgraded the customer to vSphere 6.0 a few weeks ago and I would have expected much faster commits.
Actually, they stayed the same.

Regards,
Mike

[tsightler]

Fortunately, our stuns last only for a few seconds. The whole snapshot commit takes between 5-15min. - depending on if it was an active-full or an incremental run.

This may be where there is a misunderstanding, the improvements in vSphere 6.0 are not so much about improving the length of the commit, although there is normally some improvement here as well, but on significantly reducing the stun time, which is far more disruptive. Prior to vSphere 6, even a totally idle VM with 12 VMDKs could easily stun for 30 seconds, with vSphere 6.0 that time is down to 1-2 seconds in most cases.

I would consider 1-5 minutes of consolidate time and a few seconds of stun time for a large/busy Exchange server to be excellent. With versions of vSphere prior to 6.0 I've seen Exchange/SQL servers that take 60+ minutes to consolidate (or worse, never consolidate), and stun times measured in minutes. That's the huge improvement in vSphere 6.

[dellock6]

I confirm what Tom said. In some tests I did with stressing tests, the consolidation time of a jetstress application at 10k iops was around 27 minutes, but during the time the test never crashed as it would have done before 6.0. If you want to reduce consolidation time you have to look at different technologies like vvol.