VSC 4.2 Beta is Available!

This is important for several reasons, but mostly because if you were to just download the Beta, and install it in your environment, you likely wouldn’t notice much different at first glance. I’ve been intimately involved in the development process for about a year now, and have loved every minute of it. It allows me to bring a real-life admin perspective to a software development team, and gives me a chance to “wordsmith” some occasional engineering-speak into something real people can digest.

The payload of deliverables might not be obvious to the majority of users, so I’m going to run down the hot list of what was delivered with this release.

Note: First and foremost, since it is the most common thing asked, this release does not include support for the vSphere Web client. We are diligently working on porting ALL functionality over to the Adobe FLEX framework, and it’s coming along nicely. I can confirm that the host and controller config, datastore provisioning, and other advancements have been completed, and I’ll have a video demo of that functionality very soon once it’s been cleaned up and ready for public viewing.

VSC RBAC

You’ve been asking for it for a long time, especially our larger enterprise and service provider customers. It’s here. And I’m extremely proud of what we’ve accomplished.

Combine what we’ve added into VSC natively with David Kelly’s ONTAP User Creator tool, and you’ve now got a complete solution for micro-managing user access as granularly as you or your organization sees fit. We have literally spent the better part of a year on conference calls, wiki pages, email threads, and heated debates, making sure that everyone was happy with what we’re bringing to market. RBAC is always a challenging conversation for the simple fact that no two companies/customers think about user management in the same fashion.

VSC Privileges

The first thing you should go look at is the native Roles pane in your vSphere client after installing VSC 4.2. You may have seen the few we’ve had in there before, but it has now been massively expanded to include an individual privilege for just about every granular task you could perform within the VSC.

VSC Canned Roles

We’ve also taken the liberty of creating some pre-canned roles for you to use as sample templates. I’d like to recommend that you only use these as SAMPLE TEMPLATES to clone and customize as you see fit. If we need to modify these in a future release, we don’t want to screw you up by doing so. We’re gonna warn you about it, we’re gonna recommend against doing it, but fully expect some people will modify them and run into trouble when upgrading in the future. We’re hoping to avoid this as much as possible, so please please please do not modify the canned roles themselves, but Clone the roles and then modify those.

As part of the Canned Roles, one of the things we insisted on doing was identifying which native vSphere privileges were required to perform VSC-specific actions. This is one of those awesome stories where we collaborated heavily with devs from VMware to really nail this down for YOU. We’ve taken into account as many scenarios as possible and here is what we’ve delivered…

VSC Administrator

VSC Read-Only

VSC Provision

VSC Clone

VSC Scan/Migrate

VSC Backup

VSC Restore

The coolest one of these, to me, is the Read-Only. If you look at the list of privileges available to any role, you will see a nested privilege called “View.” This solves several asks, two of which I want to highlight here…

One of the asks we’ve had for some time is the ability to hide the VSC for certain underprivileged Jr. admins, where the seniors did not want certain vSphere users/admins to even see the VSC. We’ve added this privilege specifically for this task.

Secondly, admins have always wanted a “read-only” view. Sometimes, the IT Director wants to come in and see what things look like. Sometimes, you want to be able to have certain screens up on a NOC panel. Whatever the use case, if you select none of the other VSC privileges, and select ‘View’ by itself, this will enable Read-Only and not allow a user to interact with the product, or execute any of the tasks/workflows within.

VSC Shared Credentials

When VSC 1.0 first came out, Rapid Cloning Utility (RCU), and SMVI were separate products. When they were all baked together around VSC 2.0 timeframe, they still managed their own controllers independently. One of the core charters of development for the 4.x cycle, along with clustered Data ONTAP equivalency, was to consolidate all of this into one centrally managed list within Monitoring & Host Configuration.

I’m happy to report that as of 4.2, we have completed this story by consolidating management of controllers used in Backup & Recovery as well.

We have modified the installer to put in a notification screen to note this, and we are adding some notes into the Install & Admin Guide, as well as the Release Notes to let you know what steps you need to take in order for your jobs to continue to run successfully.

The long and the short of it is: In past releases, you had to Add… storage controllers and credentials in the B&R section if you wanted to enable them for snapshot backup operations. When you go into B&R in 4.2, you will notice that list is now gone, and that the credentials have been consolidated into Monitoring & Host Config.

Upgrades from 4.x to 4.2 will leave your backup jobs intact, but they could potentially fail if they use a special user account to run. For example, let’s say you were using the account “backupadmin” in Backup & Recovery previously, but the controller(s) were listed in Monitoring & Host Config with “root.” Whatever account is configured in M&HC will override what is configured in B&R during the upgrade process. Now that these have been consolidated, your jobs will use “root” to run, as that is what is configured in Monitoring & Host Configuration. In this particular scenario, the jobs will continue to run, simply because root is root. But in the case where you might have “DiscoveryOnly” as an account for listing controllers in M&HC, and the account you used previously to run backup jobs would have higher permissions, the jobs would then fail because the “DiscoveryOnly” account does not have enough permissions to execute snapshots on the controllers.

Note: It is always ill-advised to use root, and both NetApp and myself always recommend against it. If you’re a generalist managing both, it might not be a big deal, but I would at least create a named user with the same “root” privileges so that you could at least audit what was doing what to what as time goes on.

All storage controllers, clusters, and user/pass credentials for all functional areas of VSC are now solely managed within Monitoring & Host Configuration.

VSC Bug Fixes

VSC 4.2 addresses and fixes more than 150 bugs, issues, and vulnerabilities. It’s hard to call out any one in particular because they all carry tremendous weight as a full payload, but I wanted to highlight one of the big ticket items we fixed in this release, in an effort to encourage you to upgrade your production environments as soon as possible when the final release of VSC 4.2 is available.

Upgraded to VDDK 5.1 to support W2K12

VDDK 5.1 has support for newer versions of Windows operation systems including Windows Server 2008 R2 SP1 and Windows Server 2012. P&C and O&M both have a dependency on the VDDK, so they have both been upgraded to the newest version in order for VSC to support the latest Microsoft OS’s.

VSC Beta Download & Feedback

You can find the download over at our NetApp Communities space specific to VSC. We will have download links, access to “beta” editions of the documentation, and links to this post and other content as they are developed.

This is your chance to drive innovation and changes into the product. Start up a discussion. All of us, including the devs themselves, are watching the space to answer your questions and participate in the Beta process with you!

Lastly, once we get word on the final build, I will be making a “What’s New” video to go along with the series of 4.1 videos I made in December to cover some of the items talked about in this article, and we’re also planning to have the VSC devs back on the podcast on Thursday.

5 Comments

The sentence “It is always ill-advised to use root, and both NetApp and myself always recommend against it.” should read “It is always ill-advised to use root, and both NetApp and I always recommend against it.” “I” is a pronoun that’s used as a subject. “Myself” is a pronoun that is used as an object. Here’s some help:

Hey Datacenter Dude running 4.1 of VSC in vCenter 4.. Need to know if it is required to uninstall before an upgrade to vCenter 5, then install new 4.2? Your thoughts?

http://datacenterdude.com/ that1guynick

Required? No. But it depends on which vCenter application you’re using. Are you switching to the vCenter Appliance? If so, you’ll need a separate windows installation/VM somewhere for the VSC service to run on, and then registering the plugin is easy. If it’s already separated from vCenter, no need to rip and replace, just in-place upgrade VSC. VSC 4.1 supports vCenter 5. Alternatively, if you’re running VSC on the same server as vCenter, I would recommend saving the ProgramFilesNetApp folder off-box somewhere (for the config xml files), removing it, upgrade vCenter accordingly, and reinstall the new version of the VSC. Theoretically, you could upgrade vCenter, and then upgrade VSC afterwards and “in theory” it should all work. I’m just more of a cautious admin when it comes to stuff like that. My $0.02.