VMdamentals.com

This post is the continuation of Under the Covers with Miss Alignment: I keep hearing this rumor more and more often: It appears that both snapshots and linked clones on vSphere 4.x and 5.0 are misaligned. Not having had the time to actually put this to the test, I thought it would at least be informative to give you some more down-and-dirty information on the subject.

Thinking up a View environment

So let’s assume you have a VMware View 4.x or 5.0 setup running with vSphere 4.x / 5 underneath on VMFS storage. The golden master image you use for a pool of desktops is assumed to be neatly aligned to whatever works for your storage (let’s assume you used XP aligned to 64KB).

As soon as you start using linked clones, the golden master image is first (fully) cloned out to a replica. No worries here, this replica will be aligned just like the original golden master. But now VMware starts to create linked clone desktops, which are basically multiple snapshots taken from the same virtual disk. And here comes the possible misalignment: VMware snapshot technology.



VMware Snapshots under the covers

Take a moment to think about how VMware snapshots work in vSphere 4.x and 5.0. We start out with a virtual disk. VMware will create a snapshot file as soon as you make a snapshot of a VM (or a draw a linked clone from it for that matter). Under the covers, the base image will remain unchanged, and all writes to the snapshotted VM will be placed into the snapshot file. The devil is in the details here: I just wrote “writes will be placed into the snapshot file”. If you think way back about misalignment (see Throughput part 3: Data Alignment), it was all about where (read: the offset) you started to write blocks into the file system. If your offset was exactly at a storage segment boundary, you’d be aligned and all would be good.

In a snapshot vSphere is basically doing the exact same thing: Writing blocks onto VMFS (even though it is in a snapshot file). The snapshot file contains the snapshot metadata, followed by data blocks. So what would happen if VMware did not start the writing of these blocks at a storage segment boundary? Exactly: All data blocks inside the snapshot could be placed onto disk in a misaligned manner, even if your original virtual disk was aligned.

At first glance this seems easy to fix: Just make sure the blocks get written into the snapshot file with an offset of for example 1MB. But when you look deeper you will discover an additional problem: Not all blocks will have the same size. If you add for example some 4KB blocks to the snapshot file, and then you add a 64KB block, the 64KB block is very likely to be misaligned. And since storing each block into a 1MB slot is not really a viable option, I am starting to see that this problem is a nasty one to fix. Another dirty detail: Using larger segment sizes inside an array might increase the misalignment impact, since there probably will still be some form of alignment but it gets limited to the smallest block size you ever write into the snapshot file.

I am unsure how this works in vSphere 5 right now due to a lack of testing hardware and testing time. I’m told however that this misalignment still exists in vSphere 5. As soon as I have some testing time I’ll surely follow up on this post.



Conclusion

The conclusion for now is that there is no conclusion. I am hoping to get some lab time and equipment and figure this one out. It may just be a rumor. But when thinking up how a snapshot file actually works inside it actually starts to make sense.

For the time being, think about this: If linked clones do in fact cause all blocks inside the snapshot file to be misaligned, the impact on storage in a Linked Clone enabled View environment will be even bigger than generally assumed.

One Response to “Under the Covers with Miss Alignment Part 2: Linked Clones”