vSphere 8

*** Nov 8, 2022 update ***

VMware has declared this IA release as GA now. You don’t have to change anything it magically becomes GA.

*************************

A new major vSphere release is available for download today – vSphere 8. VMware previously announced this at VMware Explore in August, but now you can actually get the binaries. VMware is using a different release mechanism this time around. The first build is called IA or Initial Availability. Sometime in November they will release the GA. The GA may be the same version as IA or it may have fixes. To me it feels like a public beta or perhaps like any recent iPhone release which has bugs and fixes the day after it debuts. For vSphere 7, we’ve seen the constant barrage of fixes over the weeks/months (latest patches up to 3g/3h) so perhaps this is a way to catch more of these problems by using a larger testing group before the official GA. As most customers run extensive testing on the new release anyway, it probably will help them in the end. In any case, there are lots of updates/changes and new features for you to consume, but I’m only going to cover those items that mean the most for the PowerMax. This is not an exhaustive list, though, so I’m bound to miss something (which when I figure out what it is I’ll cover it in another post 🙂 )


NVMeoF

NVMe/TCP

VMware released NVMe/TCP support in vSphere 7.0 U3, but made no additional updates to the general NVMeoF functionality. This meant the limitation of 32 devices and 128 paths remained, the most problematic of the caveats. In vSphere 8 they’ve expanded the supported device count to 256 (aka namespaces) and paths to 2048 for all NVMeoF. Yes, it’s not the 1024/4096 supported by FC/iSCSI but it gets us a little closer.

Adoption

In my conversations with customers unrelated to TCP, I will occasionally get asked about adoption of the NVMeoF (FC or TCP) technology. My answer so far has not deviated from “not much”. I know a couple customers using FC-NVMe, but no one with TCP yet. This makes intuitive sense to me because most of our enterprise customers use FC so they already have the infrastructure in place to do FC-NVMe. All you need is the supporting cards on the PowerMax and the HBAs on the servers which support NVMeoF (which most do). TCP is different because unless you use iSCSI, you probably don’t have a network on which you’d want to run NVMe/TCP. Yes, all customers have a network for IP traffic, but they wouldn’t want to send their storage data on those same lines. So adoption will take time – how long varies by analyst 🙂 I’m not one, but so many of them said customers would be 100% in the public cloud by now, I’d take any predictions with a grain of salt.

Updates

When adding a software adapter for TCP (see this blog post for how), I kept running into the issue where VMware was unable to recognize my NQN for the host. The NQN is what is used as the initiator when creating a host in Unisphere. So instead of seeing the Host NQN in the screen I am showing below when adding a controller, you will see Host NQN invalid. Set a valid FQDN to get valid host NQN.

The strange thing about this is that ESXi knows the correct NQN. Even with the error if I query via the CLI I get the right info:

[root@dsib1186:~] esxcli nvme info get
Host NQN: nqn.2014-08.com.emc.lab.drm:nvme:dsib1186

Something else is going on then which, unfortunately, appears to only be resolved with a reboot of ESXi. Yes, a pain to be sure in a non-development environment. In general my experience with NVMe/TCP on vSphere has not been great. For example, rebooting ESXi after completing the configuration doesn’t always result in the devices returning for me. I can’t rule out that my development environment is quirky in some way, but the issues are no less annoying.

In a previous post I also mentioned I was getting the purple screen of death from my TCP adapter on some irregular basis. With vSphere 8 the irregularity went away, but I am able to produce the issue if I put the host in maintenance mode and try to add a TCP adapter. I have a case open with VMware on this.


UNMAP

VMware has made two changes in how UNMAP works in vSphere 8, but first, I want to direct you to my recent post on UNMAP in vSphere 7 which talks about a new change in the way VMware processes the fixed or priority values. You can no longer adjust the UNMAP value on-the-fly. Changing requires unmounting and remounting the datastore. An unsupported workaround is to use the CLI. Just keep that in mind since one of these UNMAP changes is about adjusting values.

Fixed value

On the PowerMax, UNMAP has caused some grief for customers who run extremely active arrays, especially when also using SRDF. I’ve covered these type of performance considerations in this post here: VAAI and SRDF performance considerations. To help address some of these concerns, VMware took a two-fold approach. First, they added a new floor to the fixed values. Recall that UNMAP can be set by priority – low, medium, high – or by fixed value. Low priority is the default which is 25 or 26 MB/s depending on the release. In vSphere 7 if you want to used fixed values the lowest setting is 100 MB/s. In vSphere 8 it is now 10MB/s. The maximum is still 2000 MB/s.

The reduction in size may allow some customer to continue to use automated UNMAP on extremely active arrays with SRDF. Just remember that the time to UNMAP will be increased. If you want to use 10MB/s you will also have to follow the unmount/remount datastore procedure since it is not possible to set a fixed value on a datastore at creation time, only to set the priority to low or none.

Queue

The second change VMware made was to add a new scheduling queue just for UNMAP with low priority. If your box is not active (like mine in testing) your set rate will be honored; however on a heavily active one, the queue might mean you get a reduced rate. The queue is under the control of VMware and it is not something you can adjust.

Future enhancements

A future feature (from what I am told, not guaranteed) will be to limit the UNMAP rate across all hosts that access a particular datastore. Currently each ESXi host can UNMAP at the same rate as any other. I re-tested this in vSphere 8 with the new 10 MB/s setting. I used two ESXi hosts and VMware did about 8.5 MB/s on each host for a total of 17 MB/s. As these environments were a bit more active, likely the new scheduling queue had an impact reducing my 10 MB/s rate. Here is what the graphs look like for the reclaim process. Other than a 30 second blip on ESXi_B around 17:53, reclaim is consistent on both hosts.

 

Mileage may vary with the new scheduling queue depending on your activity. The idea in the future would be to throttle based on other UNMAPs coming into the datastore. I’m not sure if this would require all hosts to be in the same cluster (seems to make sense), but we’ll see. In the meantime you just want to remember this.

vVols

VASA 4

vCenter 8 supports the new VASA API version 4, though retains support for previous releases. The PowerMax does not currently have a VASA 4 yet so we will continue to use VASA 3. Therefore, when registering, that API version is displayed:

Version 4 is not required for vSphere 8 as I noted. The new API does offer some new capability including NVMeoF.

FC-NVMe

This is the first vSphere release that supports vVols with NVMeoF (with VASA 4). VMware started with FC-NVMe, rather than NVMe/TCP. As FC-NVMe has been supported by vSphere and some array vendors for longer, it seems to make sense to begin here. Other protocols will follow. Though we support FC-NVMe on our PowerMax 2000/8000 model, we are not supporting vVols on FC-NVMe. We have a small FC-NVMe installation and I don’t know that any of those customers are clamoring for vVols. If that changes, certainly I’d expect us to revisit this, but we see TCP as the future direction.

SRM 8.6

In conjunction with vSphere 8, VMware also released a new version of SRM, 8.6. The major features of this release are:

  • vSphere 8 support
  • A new end-to-end REST API
  • Automated Inventory updates when you change the environment
  • Removal of storage policy-based protection groups (prior to 8.5 this was required for stretched storage devices)

And what of the SRDF SRA? Without going into the weeds of certification, this release is what we might call an auto-cert, wherein the code that interacts with the Dell SRDF SRA does not significantly change, and thus VMware grants us support right out of the gate for both 9.x and 10.x.

I may have another post on 8.6 in the future if time allows, but certification is always the number one question I get. BTW as far as I can tell, this is the GA version, there is no IA for SRM.

Documentation

Updates for vSphere 8 in my documentation will be an ongoing, if slow process. Believe it or not, I actually work in a PowerFlex group but have tried to keep up with PowerMax since the dissolution of my previous group as there was no replacement. So unfortunately I’m all you got so please be patient. Remember, the vast majority of the information in the docs holds true for vSphere 8 even if I don’t have screenshots. If you have a particular concern, however, post a comment here as it is far easier for me to write a post on one topic than update a 300 page paper.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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

Website Powered by WordPress.com.

Up ↑

%d bloggers like this: