Getting started with vCheck

If you use vSphere and particularly vCenter, you’re probably at least familiar in passing with PowerCLI, a package of snap-ins and modules for PowerShell. This is my preferred language for interacting with the vSphere/vCenter APIs, since it has (IMO) the best documentation of the available languages and API SDKs. If not, I recommend downloading it and playing with it, it can really help you automate many of your repetitive tasks with less Flash and less right clicking.

One of the most popular tools built with PowerCLI is vCheck. It’s a framework for running a number of checks against your vSphere infrastructure and determining what operational issues are present – something every Ops team needs. It won’t replace a monitoring system such as vROps or even Nagios, but it augments such systems very well. For example, it can report on VMs that have ISOs attached, or where snapshots have been present for more than 7 days – issues that probably aren’t worth paging anyone out for, but need to be dealt with eventually. Many of us have built some homegrown solutions for this, maybe even with PowerCLI, but it is difficult to beat a tool designed to meet the needs of a large percentage of vSphere users, is actively developed by VMware employees, and is a framework that you can extend with instance-specific needs. You can always run your tools and vCheck together, too.

Let’s take a look at vCheck and how to get started with it today. We’ll download it, configure it, schedule it as a daily task, review how to enable and disable checks, and store your configuration in version control. This provides a solid base that you can tweak until it fits your specific needs just right.

Continue reading

vROps/Log Insight Integration and Troubleshooting

Update: Special thanks to Yogita N. Patil and VMware Technical Support for their assistance with the issues below!

Last week, I was trying to integrate vRealize Log Insight with vRealize Operations (vROps) so that I could ‘launch in context’ from vROps. This adds a context-sensitive action to vROps that lets you pull up Log Insight’s Interactive Analysis feature against the alert or object you are currently viewing. This makes it easy to drill down into logs with a lot less clicking around:

Launch in context is a feature in vRealize Operations Manager that lets you launch an external application via URL in a specific context. The context is defined by the active UI element and object selection. Launch in context lets the vRealize Log Insight adapter add menu items to a number of different views within the Custom user interface and the vSphere user interface of vRealize Operations Manager.

The documentation to enable this features seems pretty simple. I ran into a few problems, though…

The requirements are pretty simple, but were the first thing to trip me up. You want to be on Log Insight 3.6 and vROps 6.3. While Log Insight had been upgraded a day or two earlier, vROps was at 6.1. When performing the upgrade of vROps, it did not register its extension properly! Going into the Managed Object Browser showed there was still a vCOps 6.1 registration instance (yes, the extension is still called vCOps!). In addition, the extension was registered by IP, not by DNS. The extension needs to be in place for the steps below, or you receive even more opaque error messages, so I encourage you to verify it now. You can investigate your own MOB at a link similar to https://vcsa.fqdn.example.com/mob, and specifically look at the vROps extension at https://vcsa.fqdn.example.com/mob/?moid=ExtensionManager&doPath=extensionList%5B“com.vmware.vcops”%5D.client

Continue reading

Tag-based Veeam Backups

As I teased in Using vCenter tags with PowerCLI, I want to explore how to use tagsĀ  in a practical application. To refresh our memory, we looked at creating an Ownership category with individual tags in it, and limited VMs to having just one of the tags. We created a little script that defines our schema, in case we need to re-create it. We are going to work on a new category today for our backups. Specifically, Veeam backups, based on SDDC6282-SPO, Using vSphere tags for advanced policy-driven data protection as presented at VMworld 2015.

Defining Policy and Tags

To create our backup jobs, we need to know a few things that will translate into our tag schema. Our backup policies are defined by a combination of ownership, recovery point objective (RPO), and the retention period. For example, our Development group is okay with a 24 hour RPO and backups that are retained for a week. Operations may require a 4 or 8 hour RPO and require 30 days of backups. Each of those combinations will require a separate backup job. We can combine these tuples of information into individual tags so that Veeam can make use of them. We also need one more tag for VMs that do not need any backup at all. We can put all of this in a tag category called VeeamPolicy. Here’s what that might look like, again in PowerShell:

New-TagCategory -Name VeeamPolicy -Description "Veeam Backup Policy" -Cardinality Single -EntityType VirtualMachine
New-Tag -Name "NoRPO" -Category VeeamPolicy -Description "This VM has no backups"
New-Tag -Name "Development24h7d" -Category VeeamPolicy -Description "Development VMs with 24 hour RPO, 7 days retention"
New-Tag -Name "Operations8h30d" -Category VeeamPolicy -Description "Operations VM with 8 hour RPO, 30 day retention"
New-Tag -Name "Sales48h30d" -Category VeeamPolicy -Description "Sales VM with 48 hour RPO, 30 day retention"

Continue reading

Using vCenter tags with PowerCLI

I was recently introduced to some practical usage of vCenter tags. I used tags to build a fairly easy and dynamic set of sources for Veeam backup jobs, but before I get into that, I want to explain tags a little bit for those who are not familiar with them.

Tags are something that are pretty easy to understand conceptually. You create a category which contains a few tags. An object can receive one or multiple tags from a given category. Tags are managed by vCenter, not by vSphere, so require a license that provides vCenter for management. That’s a pretty simple explanation and list of requirements.

A Tag Category has a collection of Tags available within it. If the Category is “single cardinality”, it means that an object can only be assigned one tag in the category. This might be good for a category associated with ownership or recovery point objective (RPO). A Category can also be “multiple cardinality”, where a single object can be assigned multiple tags in a category. This would be helpful to associate applications with a VM, or a list of support teams that need notified if there is a planned impact or outage.

I’m going to show you how to manage Tags and Tag Categories with PowerCLI (Specifically with the PowerShell ISE and a profile to load PowerCLI), but you can manually create and manage them through the vSphere Web Client, under the Tags item on the left hand menu. You can create and delete and rename tags and categories there all day long, and you can right click on an object almost anywhere else and select Edit Tags to edit the assigned tags on it. When you view most objects, you’ll see an area in the Summary tab labeled Tags that will display and let you manage assignments.

Continue reading

Announcement: Github repo for common vCenter roles

Last week, I was installing some of the vRealize Suite components and was creating accounts for each component using the Principle of Least Privilege. I was sometimes able to find vendor documentation on the required permissions, sometimes I found a few blog posts where people guessed at the required permissions, but in almost no cases was I able to find automated role creation. Perhaps my google-fu is poor! Regardless, I thought it would be nice to have documented and automated role creation in a single place.

To that end, I created a repo on GitHub called vCenter-roles. I use PowerCLI to create a role with the correct permissions, and only the correct permissions. Each cmdlet will allow you to specify the role name or it will use a default. For instance, to create a role for Log Insight, just run the attached ps1 script followed by the command:

New-LogInsightRole

It’s that easy!

I will be adding some other vRealize Suite roles as I work my way through the installation, but there are tons of other common applications out there that require their own role, and not just VMware’s own applications! I encourage you to open an issue or submit a Pull Request (PR) for any applications you use. The more roles we can collect in one place, the more helpful it is for the greater community. Thanks!

Deploying Windows Images with KMS keys

I’m not all that familiar with Windows licensing models, so I stumbled into a bit of surprise with KMS keys recently. If you are using a central KMS server that you do not maintain, and someone gives you a KMS key, you can ignore it! That’s for the KMS Host, which is where the licensing happens. Your nodes will be KMS Clients and they will use a Generic Volume License Key for activation. The Client communicates with the Host, which tells the client if it is activated and provides all the necessary information for that to happen (I don’t know how the Host does that, that’s the beauty of letting someone else run that service!). In this case, you are often given media to use for the Windows install that includes the GVLK, so you don’t need to do anything but communicate with the KMS Host. It’s a pretty nice setup, all considering.

However, IF you do something silly like put the KMS Host key on your Clients, you won’t get far. The Host key can only be activated 10 times on 6 hosts, so very soon you’ll run into trouble, if not immediately. You have to switch back over to the GVLK and activate using that. Microsoft maintains a list of GVLKs for each edition of Windows. The lookup of the KMS Host is done by DNS, but you can manually configure the KMS Client as well. Once the GVLK is in place, activate the key. Here are the three commands you will need, using Windows 2012R2 Datacenter as the GVLK:

cscript c:\windows\system32\slmgr.vbs /ipk W3GGN-FT8W3-Y4M27-J84CP-Q3VJ9
cscript c:\windows\system32\slmgr.vbs /skms kms.example.com:1688
cscript c:\windows\system32\slmgr.vbs /ato

These commands need to be run from an administrator-privilege command prompt or PowerShell session.

If you are using templates, run the first command on the template. Ensure the deployment process is not adding license information. In vCenter, this means removing all options from the License Information portion of the Customization Specifications in ALL customization specs. Add the /skms and /ato commands to the existing commands in the Run Once section:

KMS Fig 1

KMS Fig 2

When you deploy a VM, it should now automatically activate itself! If you run into issues, ensure that the Client can communicate with the Host and no firewalls are blocking the communication. I’ve found that a global any/<KMS Server>/<kms port> rule in your firewalls is handy to ensure that random networks aren’t blocked from activation.

If you’re interested in learning more about Windows Licensing, Microsoft has a great amount of documentation. I suggest starting with Learn About Product Activation and then moving through the relevant sections.

vCenter 6 permissions model changes

If you have not yet upgraded from vCenter 5.5 to 6, you may want to give it a shot. vCenter 6 is much faster and introduces a lot of nice UI improvements. One of my favorites is the relatively minor change that when you delete a VM, it displays the VM name in the dialog instead of “this object”. In any case, it’s pretty swanky and I think you’ll like it.

However, there is one extremely noticeable, but (in my opinion) poorly documented change, in the permissions model for non-Administrator users and groups. In 5.x, you could assign user rights to a folder or VM and the user would be granted the proper level of access to the folder members or the individual VM. If this was your folder layout…

vCenter 6 Permissions 1

…and you wanted to grant Virtual Machine Power User access to the VM autodeploy-test, you could grant that permission to a user or group on the folder or VM here and the user could manipulate their VM just fine:

vCenter 6 Permissions 2

After upgrading to 6.0, the same user would not have permission to access the folder or VM. They might simply see Empty Inventory when looking at the VM and Templates view. To remedy this, you need to grant non-propagating permissions at the intermediate Datacenter tier (you do NOT need to grant permissions to the vCenter object). These permissions can be as limited as read-only in most cases, but as they are not propagating, you can use the same permission level (e.g. Virtual Machine Power User). The new permission is highlighted in red:

vCenter 6 Permissions 3

If you have multiple intermediate folders, you’ll need to assign the non-propagating permissions at every level. You’ll need to do the same on the Hosts and Clusters, Datastores, and Network views as well. In an additional wrinkle, Network view permissions for Distributed vSwitches cannot be assigned on the DVS, they need to be assigned on a folder containing the DVS and optionally on an individual Distributed PortGroup.

I have heard rumors that this new “feature” may be fixed soon, but until then, these changes are required for non-Administrator users to maintain their permission levels.