VMware Cloud Provider – vSAN Best Practices

I’ve been getting a few requests recently on the best practices for vSAN inside of the Cloud Provider Program (VCPP). I’d like to spend some time on how VSAN works and on what works well within the consumption program.

First things first, how is vSAN licensed inside of VCPP?

vSAN consumes points just like any other offering inside of VCPP. However, compared to our bundles, vSAN is measured on Used Capacity on disk.

There are two base options of vSAN inside of VCPP:

  1. vSAN Standard
  2. vSAN Advanced

There are add-on packages for additional vSAN functionality. Essentially, this is added to the base option to provide additional feature sets. Two add-ons are available:

  1. Enterprise Add-On for the vSAN Standard base option
  2. Enterprise Add-On for the vSAN Advanced base option

This is all summarized in the Product Usage Guide (PUG as I call it) on page 45:

To summarize:

  1. vSAN Standard is 0.04 points/GB
  2. If I use vSAN Standard with the Enterprise Add-On: 0.06 points/GB (.02 uplift)
  3. vSAN Advanced is 0.06 points/GB
  4. If I use vSAN Advanced with the Enterprise Add-On: 0.08 points/GB (.02 uplift)

Now a single VCPP is equivalent to a specific cost, that’s all subject to your agreement. Moreover, Cloud Providers with higher commitments get additional discounts. This is on top of the current vSAN Promotion going on right now too. However, you can see how this can be attractive when we talk about consumption capacity and modeling.

vSAN Automatic Detection inside of vCloud Usage Meter

One of the great things about Usage Meter is it provides automatic detection of vSAN and will report on monthly consumption. This can be broken down to a specific tenant or customer based on your Usage Meter rule set.

There’s no additional configuration necessary to setup vSAN for Usage Meter reporting. Detected vSAN clusters will appear in the Cluster History report (depicted below).

Moreover, there are four features that are automatically detected based on the Usage Meter detection:

  1. Deduplication
  2. Erasure Coding (use of RAID5/6)
  3. Stretched Cluster
  4. IOPS Limit inside of the vSAN Storage Policy

There are a few things that are critical to accurate vSAN usage inside of VCPP:

  1. Ensure you are using the appropriate vSAN license key within the VCPP model. If you intend to use vSAN Advanced, use a vSAN Advanced key. Here’s why –
    1. Usage Meter will detect what license version of vSAN is being used. If an Enterprise key is detected, and either Dedupe/Erasure Coding features are being used, vSAN Advanced + Enterprise Add-On will be charged.
    2. This is important since if you are only intending to utilize vSAN Advanced (which includes Deduplication and Erasure Coding), you’ll want to make sure you pay for the appropriate amount.
  2. Stretch Cluster and Deduplication is applied at the cluster level. Hence, all workloads that reside on that vSAN datastore will be charged accordingly, even if you have workloads that may be tied to a PFTT=0 policy.
  3. Moreover, even individual features like IOPS limit and Erasure Coding (all within the SPBM) are enabled on a per-VM basis but scoped at the cluster level. If one or more VM’s are using these features, the feature is considered to be enabled for the entire cluster.

The below table showcases how vSAN is detected and the importance of using the accurate license.

vSAN Best Practices in VCPP

Here are a few things I’ve been messaging to my Providers regarding vSAN consumption inside of VCPP.

  1. vSAN is based on actual capacity used on disk. This is inclusive of the Fault Tolerance method used along with VM Memory Swap! Therefore, a FTT=2/RAID1 is going to consume a significant amount more storage than a FTT=1/RAID5EC policy.
    1. The chart that depicts storage capacity required for each FT method:
  2. VMs used the default Storage Policy are thin-provisioned while the VM Memory Swap is thick provisioned. Keep in mind when discussing this with eager tenants that like to over-provision their storage. vSAN will only consume the storage that has been written to disk.
  3. As for the VM Memory Swap, the Storage Policy does not impact the default setting. By default, VM Memory Swap is striped (or FTT=1) to another host. This can be overridden on a host basis by using the advanced setting of “esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled”
    1. Review Duncan’s blog article more here: http://www.yellow-bricks.com/2016/02/29/vsan-6-2-sparse-swap-what-is-it-good-for/
  4. Deduplication and Compression can HELP from a cost perspective. Here’s why – Usage Meter will only detect what’s written to disk from the vSAN Cluster view. In the below example, I’ve written 101.72GB but with these efficiencies, I’ve written only 47.83GB to disk. From the VCPP program, I’d be only charged for about 47GB in space.
    1. ProTip: This is not a broad recommendation to use Deduplication and Compression just to save costs. Keep in mind the efficiencies only apply per disk group. Know your workload and I/O profile. This also applies to FTT policies – know your workload!

VCPP Sample Sizing for vSAN

So let’s go through some sample sizing on what an actual VM would be charged on a monthly basis.

Sample VM with FTT=1/RAID1 Policy

  • Sample VM: 2 vCPU, 4GB vRAM, 500GB HDD
  • SPBM – Standard Policy, FTT=1/RAID-1
  • Size Calculation
    • 500GB * 2 (FTT=1/RAID1) = 1000GB
    • 4GB Memory * 2 (Always mirrored) = 8GB
    • 1000GB + 8GB = 1008GB in total storage required
  • VCPP Cost Calculation – let’s say we are using the vSAN Advanced license which is .06 points per GB.
    • 1008GB * .06 points = 60.48 points per month
    • Let’s say my cost for a point was $1USD, this workload would cost me about $60 dollars a month.

Now let’s calculate this with an FTT=1/RAID5EC Policy. Keep in mind, all design rules apply still: still need a minimum of 4 hosts, dedupe/comp requires All Flash, etc.

Sample VM with FTT=1/RAID5/EC Policy

  • Sample VM: 2 vCPU, 4GB vRAM, 500GB HDD
  • SPBM – Standard Policy, FTT=1/RAID-5 Erasure Coding
  • Size Calculation
    • 500GB * 1.33 (FTT=1/RAID5EC) = 665GB
    • 4GB Memory * 2 (Always mirrored) = 8GB
    • 665GB + 8GB = 673GB in total storage required
  • VCPP Cost Calculation – let’s say we are using the vSAN Advanced license which is .06 points per GB.
    • 673GB * .06 points = 40.38 points per month
    • Let’s say my cost for a point was $1USD, this workload would cost me about $40 dollars a month. This is about a 32% reduction in savings compared to a RAID-1 policy. 

Now let’s say I applied a 1:5:1 deduplication and compression ratio to this sample VM. This is a conservative estimate since our standard vSAN calculator utilizes a 2:1 ratio.

Sample VM with FTT=1/RAID5/EC Policy with Deduplication/Compression Ratio of 1.5:1

  • Sample VM: 2 vCPU, 4GB vRAM, 500GB HDD
  • SPBM – Standard Policy, FTT=1/RAID-5 Erasure Coding
  • Size Calculation
    • 500GB  / 1.5 (dedupe/comp ratio) *1.33 (FTT=1/RAID5EC) = 443GB
    • 4GB Memory * 2 (Always mirrored) = 8GB
    • 443GB + 8GB = 451GB in total storage required
  • VCPP Cost Calculation – let’s say we are using the vSAN Advanced license which is .06 points per GB.
    • 451GB * .06 points = 27.08 points per month
    • Let’s say my cost for a point was $1USD, this workload would cost me about $27 dollars a month. This is about a 55% reduction in savings compared to the original model and 33% savings compared to the RAID5EC policy. 


  1. As you can see, vSAN consumption can be extremely granular from a cost perspective and will vary based on the protection scheme.
  2. Using the efficiency capabilities of vSAN along with Erasure Coding does save capacity, but remember what your workload requires!
  3. Usage Meter auto detects usage and will roll it up in the monthly reports – no additional configuration needed.
  4. As for pricing, there is a current promotion going on for vSAN inside of the Cloud Provider Program – reach out to your aggregator or VMware Business Development Manager for further information. This makes the overall vSAN pricing even more attractive on a consumption basis.



Configure vCloud Director 9.x Org Rights needed for L2 VPN Stretching – vCloud Extender

I am currently working on a new lab environment that consists of vCloud Director (vCD) Extender and vCloud Availability.

Our documentation provides a method for writing out the permissions needed via curl/API commands. I decided to take a shortcut and just use a PowerShell script.

Configuring vCloud Director Organization Rights for L2 VPN Stretching – VMware Documentation

If you don’t know what the heck, I’m talking about, vCloud Director Extender is our plugin product to migrate workloads from an on-prem environment to a vCD environment. Check out my installation guides here:

vCloud Director Extender – Installation Review

vCD Extender – Warm Migration Setup

I *thought* that vCloud Director 9.x would have all of the advanced organization permissions required for L2 stretching. I was incorrect, it’s missing a few things (really actually two, but following our exact documentation).

Per my findings, my vCD environment was missing the following from an Org Admin:

  • Organization vDC Gateway: View L2 VPN
  • Organization vDC Gateway: Configure L2 VPN

So I modified my previous script (see here) to write the required org permissions to establish and set up the L2 VPN / Data Center Connection for vCloud Director Extender.

Before I ran the script, I saw this:

Running the script….

After running the script, I now see the two new L2 VPN options available to my org admin.

Done! Now I can continue on with my L2 setup.

More to come and script is below, thanks!


# vCD Extender Permissions Setup - initially created by KiwiCloud.Ninja - modified by Daniel Paluszek - paluszek.com
# January 17th, 2018 - Modified for a vCloud Director 9.x Instance
# Script to add new OrgRights options for administering advanced Edge Gateway to a vCloud Director organisation.
# Note that Organisation roles (e.g. Organizational Administrator) still need to be edited to add these rights once
# this script has been run against their org.
# NOTE: You must be connected to the vCloud API (Connect-CIServer) with a System administrative user prior to running the script for this to work.
# Add your Org name in line 7 while the vCD instance name is added in line 8
$OrgToUpdate = 'T1'
$APIendpoint = 'vcd-01a.corp.local'

Function vCloud-REST(
[string]$Method = 'Get',
[string]$ApiVersion = '27.0',
[int]$Timeout = 40
$mysessionid = ($global:DefaultCIServers | Where { $_.Name -eq $APIendpoint }).SessionId
$Headers = @{"x-vcloud-authorization" = $mysessionid; "Accept" = 'application/*+xml;version=' + $ApiVersion}
if (!$ContentType) { Remove-Variable ContentType }
if (!$Body) { Remove-Variable Body }
[xml]$response = Invoke-RestMethod -Method $Method -Uri $URI -Headers $headers -Body $Body -ContentType $ContentType -TimeoutSec $Timeout
Write-Host "Exception: " $_.Exception.Message
if ( $_.Exception.ItemName ) { Write-Host "Failed Item: " $_.Exception.ItemName }
Write-Host "Exiting."
return $response
} # Function vCloud-REST End

# The new vCloud Director API v27.0 OrgRights for vCD Extender Preparation and Advanced Networking:
$newrights = @{}
$newrights.Add("Organization vDC Gateway: Convert to Advanced Networking", "9dc33fcb-346d-30e1-8ffa-cf25e05ba801")
$newrights.Add("Organization vDC Gateway: View L2 VPN", "105191de-9e29-3495-a917-05fcb5ec1ad0")
$newrights.Add("Organization vDC Gateway: Configure L2 VPN", "eeb2b2a0-33a1-36d4-a121-6547ad992d59")
$newrights.Add("Organization vDC Gateway: Configure Firewall", "b755b050-772e-3c9c-9197-111c286f563d")
$newrights.Add("Organization vDC Network: Edit Properties", "b0cfe989-521b-3d7f-9bc2-f23c74a99633")
$newrights.Add("Organization vDC Network: View Properties", "2c8d98ef-4acc-3be4-9214-fcb9682b7a19")

$myendpoint = $global:DefaultCIServers | Where { $_.Name -eq $APIendpoint }

if (!$myendpoint.IsConnected) {
Write-Host "Not connected to this vCloud endpoint, use 'Connect-CIServer' before running this script."

$org = Get-Org -Name $OrgToUpdate -Server $APIendpoint

if (!$org) {
Write-Host "Couldn't match organization with name $OrgToUpdate, exiting."

$rightsuri = 'https://' + $APIendpoint + "/api/admin/org/" + $org.Id.Substring($org.Id.LastIndexOf(':')+1) + "/rights"

[xml]$rights = vCloud-REST -URI $rightsuri -ContentType 'application/vnd.vmware.admin.org.rights+xml' -Method 'Get' -ApiVersion '27.0'

# Add the new API v27 'RightsReference' elements to the XML returned:
foreach($newrule in $newrights.Keys) {
$newright = $rights.CreateElement("RightReference", "http://www.vmware.com/vcloud/v1.5")

# Update the Organization with the ammended rights:
vCloud-REST -URI $rightsuri -ContentType 'application/vnd.vmware.admin.org.rights+xml' -Body $rights.InnerXml -Method 'Put' -ApiVersion '27.0'

vCloud Usage Meter 3.6.1 – Round Up Post

vCloud Usage Meter was released almost two weeks ago and I wanted to provide a summary post for those of you that will be deployed/migrating to 3.6.1.

Release Notes for Usage Meter 3.6.1 

Download Page for 3.6.1

3.6.1 does have several enhancements for vROps and vSAN reporting – so I suggest migrating as soon as possible for accurate reporting.

Remember, continue to run your existing UM instance for at least two (2) months to verify billing and monitoring accuracy (i.e. ensure you aren’t missing a vCenter instance!).

This is a minor release, so my past posts all apply here.

Migrate from existing Usage Meter to 3.6.1

Migrating to vCloud Usage Meter 3.6

End to End vCloud Usage Meter Installation (3 Parts)

Part 1 – Usage Meter Deployment

Part 2 – Usage Meter Deployment

Part 3 – Usage Meter Deployment


Correcting vROps Reporting in Usage Meter

Handy Commands for Usage Meter 

Happy Deploying!


Updating vROps Instance in vCloud Usage Meter

On new deployments of VMware vCloud Usage Meter, sometimes the wrong vRealize Operations Instance (vROps) is propagated to Usage Meter on initial connection. Today, you cannot change or modify this vROps instance. This is frustrating for new users of Usage Meter.


Well, Usage Meter relies on the Managed Object Browser (MOB) to correlate to the connected vROps instance. In some cases, a VM Administrator may have a stale or older vROps instance still registered to the vCenter environment. For correct reporting and to remove any errors from Usage Meter, this needs to be resolved. 

How do I resolve this?

Three steps to solving this:

  1. Remove the incorrect vROps instance from the vCenter MOB.
  2. Remove the incorrect vROps instance from the Usage Meter database.
  3. Register the correct vROps instance to vCenter.

Before, any of this is done, I suggest snapshotting your vCenter and Usage Meter appliance. Don’t forget to remove the snaps post-completion!

Step 1 – Remove the incorrect vROps instance from the vCenter MOB.

  1. Open your browser to “https://<vCenter-FQDN>/mob/?moid=ExtensionManager” – this is the direct link to the Extension Manager section. Type in administrative credentials to log in. 
  2. Verify you see the extensionList[“com.vmware.vcops”] extension in the list. Click on it. We are going to verify that we see the incorrect vROps instance before we remove it. 
  3. From here, click on “server.” We are going to verify that the incorrect vROps instance is showing up in the extension.
  4. Verify you see the incorrect vROps instance. 
  5. OK, press the back button twice and back to the original URL. Now we will unregister the incorrect vROps instance.
  6. Click on the UnregisterExtension Method at the bottom – 
  7. Now you’ll get a popup requesting the extension name that we will unregister. Type in “com.vmware.vcops” in the box and press the Invoke Method button. 
  8. This may take a few seconds to run. However, you will see a void message. Close the popup and refresh the main browser tab that has the MOB information. We should see that the vcops extension has been successfully removed. 
  9. Step 1 is complete.

Step 2 – Remove the incorrect vROps instance from the Usage Meter database.

Before you start this, please take a snapshot of the Usage Meter appliance. Don’t forget to remove it after you verified the change was successful! 

  1. Open up the Console (or SSH) to the Usage Meter appliance. Log into the console.
    1. Note – If you attempt to SSH, ensure you utilize the “usgmtr” account as remote root logins are NOT permitted by default.
  2. Run the “sql” command to enter the database. 
  3. Query vCOPS table to verify the record we need to delete – type in select * from “VcopsServer”; We can see I only have one instance here, so it’s ID 1. 
  4. Now we will delete ID 1. Delete entry using ID, replace [ID] with the ID gathered from above statement – so type the following two commands:
    1. delete from “VcVcops” where “vcopsServerId” = [ID]; 
    2. delete from “VcopsServer” where id = [ID];
    3. In my case, I am using
      1. delete from “VcVcops” where “vcopsServerId” = 1;
      2. delete from “VcopsServer” where id = 1;
  5. Now let’s check and make sure the vROps instance is removed from UM. Press the up arrow three times and run the select command again. As we can see, there’s 0 rows for “VcopsServer”
  6. Now type “\q” to quit out of the database.
  7. Going back to the Usage Meter console, we can now see the vROps instance is now removed from Usage Meter. 
  8. Now let’s move to re-adding the right vROps instance to Usage Meter!

Step 3 – Register the correct vROps instance to vCenter.

  1. We are now ready to register the right vROps instance to vCenter.
  2. Log into the vROps web console and navigate to Administration -> Solutions -> select the VMware vSphere name. You might see it collecting, but we need to register the plugin into vCenter. 
  3. Click on the wheel icon right under Solutions to open up the Configuration section. We will now click on Manage Registrations to re-register it to vCenter.
  4. Check the box to “Use collection credentials” and click the Register button. 
  5. This might take a moment to register the plugin inside of vCenter, but a successful message will look like the following – 
  6. Going back to my vCenter MOB tab, I can now see vcops under the ExtensionManager section. 
  7. Almost complete! Hop over to the Usage Meter console and click “Synchronize All vCenter Inventories” button right under the vCenter Server section. Then, click the Rebuild button under vRealize Operations Manager. 
  8. There we go! We now see our vROps instance. Click on Edit to put in the correct credentials. 
  9. Once you put in the credentials, you will see a message stating the credentials are correct. Complete! On the next hourly run, we should see it fully activated and the “Not yet discovered” message will be removed. 

Complete! Now, you’ll be able to monitor your vROps instance and bill based on the usage.