I was working on an update to the vVol whitepaper for our next release (VASA 3), and I realized that I failed to include a more detailed explanation of snapshot reporting in the VASA 2 paper. I’ll try to get that done in the next couple weeks (done), but in the meantime let me run through the content.
I am considering this advanced-level content, so my expectation is that the reader understands the concepts of vVols on the PowerMax. If not, please check out one of the various posts here or the documentation library which has a link to the current vVol whitepaper.
VM Snapshots
One of the benefits of vVols is the ability to use the array data services directly. Most of these are applied through Storage Policy Based Management (SPBM), but the most direct integration is snapshots. When taking a snapshot of a vVol-based VM, VMware passes off control to the array to take the snapshot using, in our case, TimeFinder technology. Array snapshots are incredibly efficient, because they are targetless. Unlike traditional VMFS, we do not need to keep delta files on the file system. All deltas are kept on the array. In addition to the targetless snapshot, if the user wishes to capture the memory state of the VM, we will generate a static vVol with that information, equaling the size of the VM memory. So far so good.
Since we keep track of changes for snapshots on the array, there is some storage usage. The question then is how is this accounted for? Do we deduct that usage from the storage container/resource? Yes and no. Let’s proceed.
Setup
I have a single storage container, Demo, which contains two storage resources:
- Demo_resource_1 is 1000 GB with an SL of Gold
- Demo_resource_2 is 1000 GB with an SL of Silver
I therefore have two storage policies, one for Gold and one for Silver.
I have a powered-on, 100 GB vVol VM, i.e a single 100 GB vmdk, created with a Gold storage policy. In the vVol datastore (our Demo storage container) I have 3 vVols – 1 – 4 GB config vVol, 1 – 8 GB swap vVol, and 1 – 100 GB data vVol, or 112 GB of allocated vVols. Here are my storage resources listing the amount subscribed.
After reviewing you may rightly ask why there is only 104 GB subscribed in the Gold storage resource when you expected 112 GB. Well, our vVol implementation is designed such that the swap vVol will always be placed in the lowest performing service level in the container, so in this case the 8 GB swap is in the Silver storage resource. As the data associated with that vVol is in memory on ESXi, the idea is to not waste space in the higher performing service levels. Personally I’d like to see the swap in the same storage resource as the config vVol for reasons I’m about to explain, but the design decision is logical.
Snapshot phantom space
Yeah, I totally made up that phrase but it will make sense. So the first thing I want to do is to take a snapshot of the VM. I’m not going to include the memory for this one, so it is completely targetless.
It finishes almost instantaneously since the array is doing it. Once it completes, let’s look at the summary information for the VM. This is the new vSphere 7 interface if it looks different.
So the VM records my single snapshot of the data vVol (100 GB) and now tells me my VM is using 212 GB total, only 100 GB of that is allocated since the other 100 GB is the snapshot. If we look at the storage resource on the array, it now indicates we have 204 GB subscribed.
And thus we have 100 GB of subscribed space that it is not associated with a vVol, or snapshot phantom space. We are simply reserving space in the storage resource. Now why would we do that? Well, let’s say I wanted to restore from that snapshot. Since we are using SnapVX technology on the array, the first thing the array will need to do is create a target device to link the snapshot to. If we do not reserve the space up-front, there is always the potential that the storage resource could be out of space by the time we restore, and thus the restore would fail. We’d like to avoid that of course.
Let’s do another snapshot, this time with the memory. Unfortunately this one is not instantaneous as we have to create a new device and copy over the memory contents. Here is the new VM totals:
Note that the storage usage is now at 320 GB, not 312 GB, because we took the 8 GB memory. However, see how the memory snapshot vVol is stored in the Silver service level, not Gold:
One of the great benefits of vVols is that you can do things like this, have vVols from the same VM be in different service levels, however in my opinion if we aren’t going to give the user a choice, I think it should be with the config vVol. Just my 2 cents. BTW, the creation of the swap file is one of those tasks that we will not fail due to lack of space. For example, if I shutdown my VM, and then change the capacity of my Silver resource to 10 GB so that my 8 GB swap will no longer fit, we will over-allocate the resource to prevent failure:
We will only oversubscribe for this one swap file, however. If I try to power on another similar VM, the swap would be placed in the Gold resource.
Storage Demand Report
OK so you’ve seen how you can account for the snapshot space in VMware and on the array, but how do you determine how much storage is being used to keep track of changes? Well, those changes are not accounted for in the storage resource. Keeping track in the storage container would be resource intensive; however that does not mean it is not possible to determine the snapshot usage in the SRP for those storage resources. We offer a Storage Demand Report which shows how much each storage group is using, including snapshot space. Each storage resource in a storage container is represented by a storage group. I am showing this in Unisphere for PowerMax but if you use Solutions Enabler the command is: symcfg -sid xxx list -demand -srp -type sg -detail -gb.
First navigate to the main dashboard of the array and select “Capacity”.
In the second step, use the System drop-down to select the correct SRP. Then in step 3 select STORAGE GROUP DEMAND Action.
The Storage Group Demand Report will list all storage resources in the container as storage groups with the prefix “_VVOLS_”. Prior to running this I made some changes to the vVol VM so that there would be snapshot data. Here you will see the snapshot information for the two storage resources. Again, the snapshot data listed here will not be accounted for in the storage resource, just the SRP. Also note that this report does not include our snapshot phantom space, since that is only reserved space in the storage resource and has no vVols in a storage group.
So you may have noticed the storage group naming for vVols is not exactly straightforward. In fact it looks downright cryptic:
_VVOLS_C1_R0_00038e2e_00038e2f
_VVOLS_C1_R1_00038e2e_00038e30
Fair enough, because we do need to decode it. We can’t do this in Unisphere unfortunately, we have to use Solutions Enabler and output the storage container to XML using symcfg. This is in the whitepaper btw. The XML format will give extra details about the container and its storage resources. Part of the detail is the UUID of the container itself and each storage resource. This is how the vVol storage group is constructed. The format is “_VVOLS_C” then the number for the order in which the container was created starting with 0. In this case the demo container is my second one, so it gets the number “1”. Next is “_R” followed by the resource number, again in the order created. The final two parts are comprised first of the last 8 characters of the container UUID then the last 8 characters of the resource UUID. I’ve highlighted the values below, but decoding:
_VVOLS_C1_R0_00038e2e_00038e2f – Gold storage resource
_VVOLS_C1_R1_00038e2e_00038e30 – Silver storage resource
If you aren’t familiar with this command, there is some good information in here, in particular it will show you how many vVols are in each storage resource. For our example, we have 2 vVols in the Gold resource and 2 snapshots, while in the Silver resource we also have 2 vVols, those being the swap vVols.
Roundup
I hope this provided some clarity to how snapshot metrics are obtained with vVols. Certainly I am pushing to make this easier in the future, at the very least to avoid the use of a decoder ring, but the data is there and now you know how to find it.
Dell PowerFlex and PowerMax with VMware 