If the time to consolidate the helper is within a certain time-frame (12 seconds), we stunned the VM and consolidated the helper snapshot into the base disk. It could be that this helper snapshot has grown considerably during the consolidate operation. Once the original chain is consolidated, we then did a calculation to see how long it would take to consolidate the helper snapshot. What we did previously is used a helper snapshot, and redirected all the new I/Os to this helper snapshot while we consolidated the original chain. You can read his great post Snapshot Consolidation changes in vSphere 6.0, here I’m only reporting a part of it: Cormac Hogan wrote a great post to explain the situation in vSphere 5.5, and also how it has been improved in vSphere 6.0. If the virtual machine has a decent I/O write activity, also the helper snapshot could grow in size, and in order to commit the changed data back into the base disk, an additional helper snapshot may be created. This process sounds simple, but once you start looking at the details are not that easy, and in some production environments this behaviour have caused problems. But vSphere 6 has introduced some changes that are probably going to make commits a problem of the past! A new consolidation methodīefore vSphere 6.0, the consolidation and commit phases of any VM snapshot has always followed the same procedure: an additional helper snapshot was created to “freeze” not just the base virtual disk, but also the snapshot disk, and once the changes stored in the snapshot disk have been merged into the base disk, the helper snapshot was also committed, and at some point the I/O was not directed anymore to the snapshot, but back to the original disk. Snapshot consolidation (or commit) operations in VMware vSphere have always been a problem, especially for large and really active virtual machines. 0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email - 0 Flares ×
0 Comments
Leave a Reply. |