Posted on by codyhosterman

PowerCLI and VVols Part I: Assigning a SPBM Policy

There are a variety of ways to assign and set a SPBM Policy to a VM. I recently put out a workflow package for vRO to everything VVols and Pure:

vRealize Orchestrator VVol Workflow Package

I also specifically blogged about assigning a policy to a VM with vRO:

Assigning a VVol VM Storage Policy with vRO

How do you do this with PowerCLI?

Doing this in PowerCLI is fairly straight forward. There are a variety of cmdlets available that make this quite easy:

There are many more SPBM-related cmdlets, but for now let us focus on these.

Getting SPBM Configuration of a VM

The VM I want to assign a policy to is called “testvm”. So I will store that in $vm:

What is the current configuration of my VM now from a SPBM standpoint? What policies are currently assigned? What is the compliance?

The Get-SpbmEntityConfiguration cmdlet will do this! There are two parts of a VM that can have policy assigned to it, the home (config VVol) and its virtual disks (data VVols). The Get-SpbmEntityConfiguration cmdlet will return the storage policy assigned to those objects and its compliance. The object is checks depends on what object you pass into it.

If you pass a VM object into it, it will check the SPBM configuration of the home directory only.

If you pass in a hard disk or multiple hard disks you will get those. So the get-harddisk cmdlet can do that.

Store that in a variable and pipe it into Get-SpbmEntityConfiguration, or just include the cmdlet directly in the line and pipe the result into it:

You can also pass in both at once:

The key is, be explicit with the objects you want to check.

So as you can see, my VM home has the policy of “VVol No Requirements Policy” and so do my two virtual disks.

Checking SPBM Compliance

One of the great benefits of SPBM and VVols is the ability to not only set configuration, but ensure that configuration is still properly applied. This can be achieved through compliance checks.

Running a compliance check is done through the Get-SpbmEntityConfiguration, just like above. There is just one eccentricity you should be aware of.

There is a parameter to the cmdlet called “CheckComplianceNow”. When that is NOT added, the cmdlet will only return the latest compliance status. It does not actually check to see if the VM is still compliant.

If you add the CheckComplianceNow parameter, it will actually have vCenter ask the underlying array, is the storage still configured according to the assigned policy?

So my utterly profound thoughts:

  • If you just want to retrieve the storage policy of the object, leave off the compliance parameter–there is no need to add it.
  • If you want to check compliance, add it.

Pretty straight forward. The cmdlet does return the time stamp of the last compliance check if you need to know.

Getting SPBM Policies

You can list your storage policies like so:

Get-SpbmStoragePolicy

If you want to filter by provider you can use the namespace parameter. So if I want to only find Pure Storage policies, you can use “com.purestorage.storage.policy”:

One of my policies is called FlashArrayVVol and all it says is that any VM or virtual disk assigned to it should be VVol-based and on any given FlashArray.

I will store this in a variable called $policy:

You can see the policy rules in the AnyOfRuleSets property:

Assigning a SPBM Policy

My virtual machine home and its two virtual disks currently have the default VVol policy. I want to assign them a new policy.

This is done via the Set-SpbmEntityConfiguration command. It works in a very similar way as Get-SpbmEntityConfiguration.

The main difference, is you do not pass in the VM or harddisks directly, you pass in their storage policy result, which is yielded by the Get-SpbmEntityConfiguration. You can store the harddisk (like I do in $hd) with the get-harddisk cmdlet.

So I would store the Get-SpbmEntityConfiguration result in a variable I will call $vmConfig:

The key here again, is specify the configuration of every object you want to change. List the VM config and each hard disk config you want to change. If it is not listed, it will not be changed.

So let’s assign it a policy that just says, I want this VM to always be on VVol and a FlashArray. So the policy described in the previous section–“FlashArrayVVol” . My policy is still stored in $policy.

So I will pass my $vmConfig in and also my policy. You can pipe in the VM/harddisk configs, or add it with the configuration parameter.

This will set the policy to the VM and/or disks and return the new status.

Assigning a SPBM Policy and Replication Group

The above assigns a standard VVol SPBM policy. But if you use a “replication” type policy, you also need to set a replication group (consistency group). For a FlashArray perspective, this means that you are using a VM storage policy that has either a local snapshot capability, or a replication capability.

In other words, the policy uses the namespace “com.purestorage.storage.replication”

If I assign this policy, I need to also assign a replication group. From a FlashArray perspective, this is what we call a “protection group”. It is a array consistency group that has a local snapshot policy and/or a replication policy.

Though you can’t just assign any replication group–it has to be one that adheres to that policy.

This can be identified also fairly easily.

The policy I want to assign requires that my storage be configured with a local snapshot interval of 1 hour and a remote replication interval of 1 hour. I called this policy “1 hour rep one hour snap”.

I stored that in my $policy variable.

Next I can pipe that to the cmdlet get-spbmreplicationpolicy. This will return all replication groups that are compliant with that policy.

I will then store the result in $repGroups. I can now assign this to my VM. Using the same method as the previous section, but adding the replication group. I want to add it to my “gold” group, so I will pass only that in by indexing to that part of the variable $repGroups ($repGroups[0])

I can now assign the policy and the replication group:

We can see in the vSphere Web Client that the VM is fully configured with the policy and the replication group:

If we look at the array itself, we can see the corresponding volumes are in the FlashArray protection group with a 1 hour replication policy and a 1 hour snapshot policy

That’s it for the first post! I will be digging into a lot more with PowerCLI and SPBM and VVols quite soon. Stay tuned.

24 Replies to “PowerCLI and VVols Part I: Assigning a SPBM Policy”

  1. Pingback: PowerCLI and VVols Part V: Array Snapshots and VVols | Cody Hosterman

  2. Hey Cody, I noticed that you didn’t note the step where you set the $hd variable. You have a screenshot showing $vm | get-harddisk |Get-SpbmEntityConfiguration. I had a customer confused by this today. Just a thought

    Reply
  3. Pingback: PowerCLI and VVols Part VI: Running a Test Failover | Cody Hosterman
  4. Pingback: PowerCLI and VVols Part VII: Synchronizing a Replication Group | Cody Hosterman
  5. Pingback: PowerCLI and VVols Part VII: Running a Failover–Planned Migration | Cody Hosterman
  6. Pingback: PowerCLI and VVols Part III: Getting VVol UUIDs from the FlashArray | Cody Hosterman

  7. I am not able to get the replication group details. Not sure what is missing in my configuration. Any comment.

    PS C:\Windows\system32>
    PS C:\Windows\system32>
    PS C:\Windows\system32> Get-SpbmStoragePolicy -NameSpace com.purestorage.storage.replication | ft -autosize

    Name Description Rule Sets
    —- ———– ———
    vVolReplication FlashArray Storage Policy. Remote Replication every 10 Mins, retained for 30 Mins. {(com.purestorage.storage.policy.PureFlashArray=True) AND (com.purestora
    FlashArray Replication 4 HOURS FlashArray Storage Policy. Remote Replication every 4 Hours, retained for 8 Hours. {(com.purestorage.storage.policy.PureFlashArray=True) AND (com.purestora

    PS C:\Windows\system32> $vm|Get-SpbmEntityConfiguration

    Entity Storage Policy Status Time Of Check
    —— ————– —— ————-
    EILABRH7VVOL1 vVolReplication compliant 2/1/2020 2:53:45 AM

    PS C:\Windows\system32> $policy = Get-SpbmStoragePolicy -Name vVolReplication | ft -autosize
    PS C:\Windows\system32> $policy

    Name Description Rule Sets
    —- ———– ———
    vVolReplication FlashArray Storage Policy. Remote Replication every 10 Mins, retained for 30 Mins. {(com.purestorage.storage.policy.PureFlashArray=True) AND (com.purestorage.storage.repl

    PS C:\Windows\system32> $policy = Get-SpbmStoragePolicy -Name “vVolReplication”
    PS C:\Windows\system32> $policy

    Name Description Rule Sets Common Rules
    —- ———– ——— ————
    vVolReplication FlashArray Storage Policy. Remote … {(com.purestorage.storage.p… {}

    PS C:\Windows\system32> $policy | Get-SpbmReplicationGroup

    Get-SpbmReplicationGroup : 2/1/2020 3:15:24 AM Get-SpbmReplicationGroup The string was not recognized as a valid DateTime. There is an unknown word starting at index 0.
    At line:1 char:11
    + $policy | Get-SpbmReplicationGroup
    + ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Get-SpbmReplicationGroup], VimException
    + FullyQualifiedErrorId : Core_BaseCmdlet_UnknownError,VMware.VimAutomation.Storage.Commands.Cmdlets.Spbm.Replication.GetSpbmReplicationGroup

    PS C:\Windows\system32> Get-SpbmReplicationGroup –vm EILABRH7VVOL1

    Get-SpbmReplicationGroup : 2/1/2020 3:25:33 AM Get-SpbmReplicationGroup The string was not recognized as a valid DateTime. There is an unknown word starting at index 0.
    At line:1 char:1
    + Get-SpbmReplicationGroup –vm EILABRH7VVOL1
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Get-SpbmReplicationGroup], VimException
    + FullyQualifiedErrorId : Core_BaseCmdlet_UnknownError,VMware.VimAutomation.Storage.Commands.Cmdlets.Spbm.Replication.GetSpbmReplicationGroup

    Reply

        1. It seems the issue is with PowerCLI SDK. I have a support case with VMware and yet to get an update. Have you got a chance to test the vVol replication using vSphere 6.7 Update 3 ?

          Thanks,
          Kannan

          Reply

          1. Let me give it a try. Was working on it the other day a bit but got caught up in other priorities. Will do my best to test today or tomorrow

          2. So I tested with vCenter Appliance 6.7 Update 3b and PowerCLI 11.5 and it worked. Though I am also on Purity 5.3.4, so it is possible that makes a difference

  8. Do we need to create the same vVol datastore name and replication group name at source and target site storage array? I couldn’t find many details about pre-requisites to configure and test vVol replication successfully.

    Reply

    1. No the name doesn’t matter today (or won’t ever). The vVol datastore just needs to be mounted prior to doing a failover on the target. Are next Purity release (likely 5.3.5, but it could be slightly after) will have a significant amount of replication management improvements–as we have been working on it heavily over the last 6-8 months for the upcoming SRM vVol support. When that is out I will definitely be making it known and it will certainly be the target release for users of vVols in general, but absolutely users of vVol replication.

      Reply

  9. Thanks, Cody for taking the time to test it. We have identified the cause with the help of VMware GSS and Engineering team. One of the unused VASA provider configured in my Lab VC was returning the last sync time value as unknown and the SDK doesn’t have the logic to handle unknown value. It will be fixed in the upcoming PowerCLI version.

    I have removed the unused provider and continuing my testing.

    Thanks,
    Kannan

    Reply

    1. Interesting thank you! Good to know. This might be the root of similar problems we have seen with PowerCLI and VASA

      Reply

  10. I read somewhere that the Pure Storage async replication works based on the snapshot. I am just wondering, do i need to create a production group with a snapshot and replication schedule or just replication schedule is sufficient for vVol replication.

    What is the best practice?

    Reply

    1. Our replication is based on snapshots from a protection group so for replication to work with vVols there must be a pgroup on the array with a replication target. A replication schedule does not have to be enabled but in general should be

      Reply

  11. If I make a change in the production group replication interval or snapshot polices, Does VASA provider push the changes to the vCenter server level SPBM VM storage policies?

    Or Do I need to make the changes in the VM storage policy manually and remediate the VM to make it compliance?

    Reply

  12. You need to make changes in VMware. There is no mechanism in VASA to push policies etc into vCenter. Especially since a policy can be used on many arrays, a change on one array should not change a policy in vCenter. Policies are about “this is how I want my VM to be configured” not “this is how my array is configured” So if an array changes and it can’t match that policy anymore, than VMware will mark the VMs on it using that policy as non-compliant. Then you need to make a choice: move the VM to an array that can, change the policy, or change the array.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.