vSphere 7.0 U2 – iSCSI, vVols

VMware recently released Update 2 for vSphere 7, both ESXi and the vCenter. I’m going to cover a few of the new additions in this release, though not all, so I have put in the links to the READMEs. VMware updates used to be minor events, but more and more they are packing these with features akin to a major point release. I don’t know the reason for this, but it’s all good for us.

Most of the features that are of interest to me in our space are vVol related, though let’s start with one for iSCSI.


Well since I’ve covered iSCSI recently, I will note a big change in U2. This update increases the path count for iSCSI devices from 8 to 32, quite a huge jump. In many production FC environments I see 8, but plenty of customers use 16. Similarly, I’m told customers running iSCSI paths at 16 or even 24 is quite common. So this is good news. Sometimes the simplest changes are the best.

Software adapter

I wasn’t sure whether to include this tidbit, but I’m going to err on the side of caution. One strange occurrence I had in my iSCSI environment during the upgrade is that VMware changed my iSCSI software adapter alias. You can imagine my surprise after my upgrade when I lost all access to my datastores and VMs. This occurred on every host I upgraded where iSCSI was installed. Here is the before and after of the alias on one host, with the blue box showing what part of the name changed.

I’ve informed VMware and they indicated no testing on their side brought out this issue; however they said they would do additional testing just to be sure. I’ll update the post if anything comes of it. By the way, to fix this you either need to rename the alias in vSphere back to the original name, or what I did was update the name in my initiator group to conform to whatever reason VMware did this. As my environment is just a lab, it’s not a big deal, but had this been a production environment, it would have been a different story. Hence, that’s why I put it here. 

Now the vVol updates.


As I noted at the start, I’m focusing on items that are more relevant to our vVol PowerMax implementation. For example, there are some changes to snapshots with CNS and SPBM that do not directly impact us, so I do not have it here.


VMware has added a new namespace, stats, to the esxcli storage vvol command.

The command will allow you to monitor some performance stats, and, VMware suggests, identify issues with a slow VASA Provider. You can enable or disable all stats, or just a collection of them through the add/remove commands (though this requires an entity switch which honestly I still haven’t figured out). From my analysis there are 76 different stats, but not all will have data. You can get a list by running esxcli storage vvol list, whether or not stats are enabled:

If you want to view a single stat, you can run the get command, passing the namespace, or Stat Node.

Now the documentation on this is minimal unless Google is failing me. I’ve had to do a lot of trial and error. What I have discovered is if you enable the stats – esxcli storage vvol stats enable – VMware will create logs in the /var/log directory called vvol-stats-<number>.log. In these logs you will see stats dumped every 30 minutes.

So how truly useful are these statistics and is there a performance impact if I enable them? I can’t honestly say I have the answer to either of those questions. You can see above some of the information you can get. In particular there are lots of historical latency numbers. It’s not clear how to interpret those or what to do with them. Hopefully in the future VMware will provide more guidance. If I get that, I will update this post.

Protocol Endpoint queue

VMware increased the default PE queue to 256 from 128 as there was a known issue where the queue depth of the device did not match the PE one. As I’ve explained in the vVol paper, generally it is unnecessary to adjust this value, but certainly now you don’t have to worry about being held back by the PE default. Here is the setting from U2.

Config file size increase

Currently when you create a vVol VM, all the config files (.vmx, vsd, etc.) are stored on a single 4GB vVol device which is formatted with VMFS, kind of like a config datastore. This size is more than enough to accommodate this information and I should note this size is universal across vVol vendors. In U2, VMware now permits users to create a larger config file (for us that means up to 16 TB) if they so desire. Increasing the config file size means you can create a folder in a vVol datastore that can store large files (e.g. ISOs). Yes, a folder because you can’t store the ISO without a folder as a vVol datastore does not have a file system like VMFS, only the config vVol does. Previously you had to put the ISO on a traditional VMFS/NFS datastore. But, in order to create the folder of a size larger than 4 GB you have to use the functionality available in the MOB (Managed Objects – https ://<VC_SERVER>/mob), which you may be familiar with if you had to uninstall VSI. I did a short demo showing how to do this. Remember, if you create a folder in the vVol datastore in vCenter, it will only be 4 GB. You have to use the process in the demo to create anything bigger. It’s a bit of a pain, though I would guess VMware will have PowerCLI support for it soon. In any case you probably don’t create repositories for ISOs often and hopefully you’ll see the process isn’t difficult. I should note that there are many navigation paths in /mob to the same location, so you don’t necessarily have to follow my path if you are familiar with the hierarchy.

Cloud Native Storage (CNS)

This new feature I particularly like. VMware has added mapping of the CNS PV vmdk to the vVol device on the array. I covered CNS here if you need a quick refresher. I’m ashamed to say we do not provide mapping of the vmdk to vVol device in our vCenter plugin, so currently you can only get this information through Unisphere (covered in vVol paper.) But for First Class Disks (FCD) VMware will give you the device ID or for us the WWN Mobility ID. Here is the view prior to U2:

All you get there is the Volume ID. Now check out U2:

There is my WWN in the red box. And with that WWN I can now pull the device ID from Unisphere or Solutions Enabler. I’m going with SE below to discover the ID is 000F0.


One final mention here for SRM. If you install U2 and you run SRM, you also need to upgrade SRM to the newly released 8.4 version. This kind of goes along with the idea that U2 is more than just a simple release and necessitates a change to SRM. We support SRM 8.4 so no worries on our side.


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: