Migrating From SCSI To NVMe on vCenter (Part 1 – Live Migration)

This is going to be broken up into two parts- first, a live migration where no VMs get powered off during the migration; second, a migration where you temporarily power off VMs attached to the SCSI datastore.

Why would you want to do it one way or another?

Pros of live migration:

  • No VM downtime
  • Simpler configuration changes and overlap. Less to go wrong or mess up

Pros of powering off VMs:

  • The total migration time will be significantly less because no data will have to be moved. Currently VMware doesn’t support XCOPY (even on the same array) for NVMe-oF

Great, you’ve decided on a live migration for your VMs because you don’t care about how long it takes; you just want to minimize downtime of your VMs as much as possible. If you haven’t already, you’ll need to follow the guides Pure Storage has for setting up NVMe-oF in your environment.

Once you’ve configured NVMe-oF in your environment, you’ll need to create the namespace (volume), connect it to the appropriate host group, create the NVMe-oF datastore in vCenter and finally storage vMotion your VMs from the SCSI datastore to the NVMe datastore.

Create the Volume

From a FlashArray perspective, this is identical to SCSI except for the slightly different terms and labels. Cody wrote a nice article explaining the differences. Log into your FlashArray, select (1) Storage then (2) Volumes then click the (3) + on the right hand side of the GUI.

In the window that pops up, populate a (1) Name for the namespace (volume), give it a (2) Provisioned Size then click (3) Create.

Note the volume serial number by going to (1) Storage then (2) Volumes, finding the name of your (3) Volume, then (4) clicking on the hyperlink name of it.

On the next window, note the Serial of the volume. We will use this later in vCenter to validate that we are connecting the right namespace.

Connect The Volume To the Appropriate Host Group

Still in the FlashArray GUI, go back to (1) Storage, select (2) Hosts, then select the (3) Host Group you have created for your NVMe-oF hosts. In this case, I am setting this up for NVMe-FC but the steps will be the same for NVMe-RoCE after you have followed the previously linked KB articles.

Next, click the three vertical dots (I think this is called a hamburger) and select Connect.

For the last step in the FlashArray GUI, select the (1) Namespace (volume) you created before then click (2) Connect.

Create The NVMe-oF Datastore

Switching over to vCenter, we’ll first want to create a datastore from the namespace that we’ve just presented to our host group. This process is easier than with SCSI datastores because you do not have to rescan the storage adapters- all you need to do is create a datastore on top of the NVMe namespace that is already present.

(1) Right click on the vSphere cluster you’ve presented the namespace to, hover over (2) Storage, then click (3) New Datastore.

Select (1) VMFS (currently vVols is unsupported by VMware with NVMe-oF) and click (2) Next.

Specify a (1) Name for your datastore, (2) Select a host that the namespace was presented to, select the (3) namespace from the list and click (4) Next. Validate the serial number of the namespace (volume) from the FlashArray GUI before in the Name column.

Select (1) VMFS 6 (who uses 5 anymore anyways?!) and click (2) Next.

Click (1) Next.

Review the details and click (1) Finish.

Validate the hosts are connected to your newly created NVMe-oF datastore by going to the (1) Storage tab, selecting the (2) Datastore Name and clicking on the (3) Hosts tab. If anything looks incorrect here (not all hosts from the cluster are connected, etc), please review your NVMe-oF configuration for issues.

Storage vMotion the VMs from SCSI-backed Datastore(s) to NVMe-backed Datastore(s)

Staying in the vCenter GUI, select the (1) Hosts and Clusters tab, right click on the (2) VM you want to migrate from SCSI to NVMe then select (3) Migrate… from the list that pops up.

Select (1) Change storage only from the window that pops up and click (2) Next.

Select the (1) NVMe datastore you created before then click (2) Next. Optionally you can modify the storage policies for the VM and the virtual disk format.

Finally, verify the details of the migration and click (1) Finish.

And now wait until the VM has migrated to the NVMe-oF datastore. Migrations in general can be very daunting, but luckily with NVMe-oF, it can be extremely simple. Hopefully you found this helpful.

Pure Storage vSphere Remote Plugin™ 5.1.0 launch: vVol Point-in-Time Recovery

We are excited to announce the launch of the latest version of Pure Storage’s remote vSphere plugin, 5.1.0. It includes a number of bug fixes PLUS a highly sought after feature: vVols VM point-in-time (PiT) recovery!

Why am I excited about this feature?

With vVol PiT VM recovery, you can now easily recover an entire VM that was accidentally deleted (and eradicated) or you can restore the state of a VM back to a point in time that you took a snapshot from vCenter directly while using Pure’s vSphere plugin.

The requirements of this are Pure’s vSphere remote plugin 5.1.0 and Purity™ 6.2.6 or higher for PiT revert and for PiT VM undelete with a vVol VM that has had its FlashArray™ volumes eradicated from the FlashArray itself. If you’re undeleting a vVol VM that has not been eradicated yet, that functionality is present for Purity versions 6.1 and lower.

For PiT VM revert, you will also need to make sure that you have snapshots of all of the volumes associated with the vVol VM except swap- at least one data volume and one configuration volume.

For VM undelete before the volumes have been eradicated, you will need a snapshot of the vVol VM’s configuration volume.

For VM undelete after the vVol-backed VM has been eradicated, you’ll need a FlashArray protection group snapshot of all the VM’s data volumes, managed snapshots and configuration volumes.

Rather than rehash what my teammate Alex Carver has put a lot of work into, I’m just going to link to the KB and videos he created:

Download the new plugin (part of Pure’s OVA), read the release notes and test out vVol PiT recovery today! Like a lot of things, it’s better to have some understanding of what’s happening and why before needing something that might be part of your recovery process. Please note that you can also upgrade in-place from 5.0.0 to 5.1.0 (and future remote plugin releases) by following this guide.

Native Pure Storage FlashArray™ File Replication – Purity 6.3

With the release of Purity 6.3, Native FA File replication has been added to the Pure Storage FlashArray™ software. This adds an often important feature to the FA File folder redirection solution I wrote about last year. Pure Storage is referring to this feature as ActiveDR for File Services.

ActiveDR for File Services is a useful feature if you’ve set up or are going to set up folder redirection on FA File and you would like the file data to be replicated asynchronously to a different array, whether that FlashArray hardware is at the same site or a different one. This feature is included with FlashArray.

This allows you to use your FlashArray for native block and file workloads that need the protection that replication provides and allow you to benefit from the great data reduction rate that FlashArray is known for with those replicated file sets.

Now, if you lose a site or an array for some reason, the file workload you have hosted on FA File can be recovered natively on FlashArray easily and quickly.

There are some differences between file and block workloads when it comes to ActiveDR replication. You can read more in the ActiveDR for File Services section of this Pure KB.

Force the Invoke-RestMethod PowerShell cmdlet to use TLS 1.2

I wrote about some security changes in the FlashArray operating environment (called Purity) version 4.7 a month or so back. This was concerning the deprecation of SSL and TLS version 1.0, forcing all (management) connections to the FlashArray to use TLS 1.1 or 1.2 (read this here).

Our PowerShell SDK was enhanced so it would use the appropriate security connection type so users of that do not need to worry as long as they upgrade our SDK. But what about the few remaining functions that people might use that the PowerShell SDK doesn’t cover? As there are a few REST calls that are not built into the SDK (yet).  Continue reading “Force the Invoke-RestMethod PowerShell cmdlet to use TLS 1.2”

Introducing FlashArray Purity Release 4.6

It has been awhile since I have done a solely Purity operating environment post and with the recent release of our Purity 4.6 operating environment I thought it was a good opportunity to do one. I will overview some new features and changes, some big some small.

4.6 has been in Directed Availability (DA) for some time, so many of you might already have this, but I decided to wait until it was closer to GA (this is imminent) to post. Not a gigantic release, but I think there is some cool stuff in it regardless.

Here is a brief listing of some of the new stuff:


  • VLAN tagging Introduces support for VLAN tagging for iSCSI connections to the FlashArray. VLAN tagging allows multiple VLAN interfaces to be configured on physical iSCSI ports.
  • Replication network bandwidth throttling Introduces the ability to set a maximum network bandwidth utilization for replication between two connected arrays. Allows configuration of a default maximum bandwidth and/or a time window during which a different maximum bandwidth is enforced.
  • Deduplication-preserving replication Introduces the ability for Purity to preserve inline deduplication savings when transferring replication data to a target array, to reduce the network bandwidth utilization.
  • Protection group copy Introduces the ability to copy protection groups, including their member hosts, volumes, and snapshots. Protection group copy is supported in the CLI and REST API.
  • The Pure Storage SMI-S Provider Release 1.0.0 of the Pure Storage SMI-S provider is embedded in Purity 4.6.0 release. SMI-S enables both hardware and software interoperability between different vendors’ enterprise storage products and allows vendors to develop to a single standard interface. For more information, please see the SMIS-S release notes.
  • Improved readability of graphs in the Purity GUI In the GUI Dashboard and Analysis tabs, changes the color of the write graph to orange to distinguish it from the blue read graph.
  • CLI Changes This is mostly to cover the new features above
  • REST API version 1.5 Some new REST calls for new features and general enhancements and fixes for our REST API service.

Continue reading “Introducing FlashArray Purity Release 4.6”

FlashArray //m and VMware Integration–What do you need to know?

Last week Pure Storage introduced the latest iteration in the FlashArray product line: the FlashArray //m. While Pure Storage has traditionally focused on software innovation from a technical standpoint, we decided that the only way to stay ahead of (and lead) the curve was to innovate in the hardware realm as well. Therefore, for the last few years, development on producing a hardware platform that could keep up with compute and storage speed and capacity leaps has been at full tilt. This produced the brand new FlashArray //m.


Continue reading “FlashArray //m and VMware Integration–What do you need to know?”

FlashArray XCOPY Data Reduction Reporting Enhancement

Recently the Purity Operating Environment 4.1.1 release  came out with quite a few enhancements. Many of these were for replication, certain new GUI features and the new vSphere Web Client Plugin is included. What I wanted to talk about here is a space reporting enhancement that was made concerning VAAI XCOPY (Full Copy). First some history…

First off a quick refresher on XCOPY. XCOPY is a VAAI feature that provides for offloading virtual disk copying/migration inside of one array. So operations like Storage vMotion, Cloning or Deploy from Template. Telling an array to move something from location A to location B is much faster than having ESXi issue tons of reads and writes over the SAN and it also therefore reduces CPU overhead on the ESXi host and reduces traffic on the SAN. Faster cloning/migration and less overhead–yay! This lets ESXi focus on what it does best: manage and run virtual machines while letting the array do what it does best: manage and move around data. Continue reading “FlashArray XCOPY Data Reduction Reporting Enhancement”

Pure Storage Web Client Plugin version 1.1.13

I have done a few posts on here that involve the Pure Storage Plugin for the vSphere Web Client (here and here) since I joined. Well here is another. We just released a new version of the Web Client Plugin (I am going to refer to it as WCP for the rest of this post because I am a lazy typist). We bundle the WCP into Purity and therefore the WCP is installed, updated and uninstalled from our GUI/CLI to vCenter (yes we do also offer a mechanism to update it outside of upgrading Purity itself). Our latest release of Purity, 4.0.12, includes WCP version 1.1.13–while there is no new functionality there are two important fixes.


Continue reading “Pure Storage Web Client Plugin version 1.1.13”

Using VMware Log Insight with the Pure Storage FlashArray

I’ve done a few VMware Log Insight posts in the past year but I have yet to do one for Pure Storage. Log Insight is a product that I really love and VMware has been updating it like crazy since its initial release. Just recently they announced the 2.0 version of Log Insight (more info here). Besides just being functionally useful it is VERY easy to use–from kicking off the deployment (it is an OVA) to first use it takes about ten minutes maximum.


Continue reading “Using VMware Log Insight with the Pure Storage FlashArray”

Purity 4.0 Release: New hardware models, replication and more!

Ah my first official post during my tenure at Pure and it couldn’t have happened at a better time! Just in time for the Purity 4.0 release which we just announced today. While there are plenty of under-the-cover enhancements I am going to focus on the two biggest parts of the release: new hardware and replication. There are other features such as  for example hardware security token locking but I am not going to go into those in this post. So first let’s talk about the advancement in hardware!


Continue reading “Purity 4.0 Release: New hardware models, replication and more!”