Part of my role at VMware is to work closely with our customers and partners, sharing experiences and feedback with internal VMware Product Management and Engineers to help make our products better. One area that has been dominantly more focused than others over the last 12 months has obviously been vCenter Single Sign-On.
Due to this feedback, one of the drivers for the new vCenter Single Sign-On was to provide backwards compatibility and to highlight this, a recent Knowledge Base article released.
A few weeks ago I saw on an internal email thread an ask from a customer via their VMware sale engineer. The customer was using AutoDeploy and Host Profiles. As part of this process, they were creating a local user on their ESXi hosts and when they connected to the host via the vSphere Client application on Windows, they were worried to see that the user was created with Shell Access already granted! As you can imagine, that’s probably not something you want done by default. Even more so when you’re in an environment that has compliance concerns. And especially when you have the Security Guy looking over your shoulder!
Well, like our friends from Down Under would say, “No Worries Mate”. What you are seeing here is a UI bug in the vSphere Windows Client. As you know, the vSphere Windows Client has been superseded by the new vSphere Web Client. But at the moment, it’s the main tool for configuration by those who connect to ESXi servers. With the vSphere Web Client being the current and future client user interface for vCenter Server managed objects and resources, the “old” vSphere Client may, at times, not be as current as we’d like.
VMware vCenter Multi-Hypervisor Manager is a component that enables support for heterogeneous hypervisors in a VMware vCenter Server environment. It provides the following benefits to your virtual environment:
An integrated platform for managing VMware and third-party hypervisors from a single interface.
A hypervisor choice for the different business units in your organization to accommodate their specific needs.
No single hypervisor vendor lock-in.
When you add a third-party host to vCenter Server, all virtual machines that exist on the host are discovered automatically, and are added to the third-party hosts inventory.
The ability of vCenter Multi-Hypervisor Manager to migrate virtual machines from third-party hosts to ESX or ESXi hosts is implemented by exposing the capabilities of vCenter Converter Standalone in the vSphere Client. See VMware KB article 2048927 for information about dependency between vCenter Multi-Hypervisor Manager and vCenter Converter Standalone.
vCenter Multi-Hypervisor Manager 1.1 introduces the following set of basic management capabilities over third-party hosts:
Third-party host management including add, remove, connect, disconnect, and view the host configuration.
Ability to migrate virtual machines from third-party hosts to ESX or ESXi hosts.
Ability to provision virtual machines on third-party hosts.
Ability to edit virtual machine settings.
Integrated vCenter Server authorization mechanism across ESX/ESXi and third-party hosts inventories for privileges, roles, and users.
Automatic discovery of pre-existing third-party virtual machines
Ability to perform power operations with hosts and virtual machines.
Ability to connect and disconnect DVD, CD-ROM, and floppy drives and images to install operating systems.
This release of VMware vCenter Server 5.1 Update 1 offers the following improvements:
vCenter Server is now supported on Windows Server 2012
Additional vCenter Server Database Support: vCenter Server now supports the following databases.
Microsoft SQL Server 2012
Microsoft SQL Server 2008 R2 SP2
Additional Guest Operating System Customization Support -vCenter Server now supports customization of the following guest operating systems:
Windows Server 2012
vCenter Essentials no longer enforces vRAM usage limit of 192 GB With vSphere 5.1 Update 1, the Essentials and Essentials Plus licenses no longer restrict virtual machine power-on operations when the vRAM usage limit of 192 GB is met.
Resolved Issues – This release delivers a number of bug fixes that have been documented in the Resolved Issues section.
With the release of vCenter 5.1 adding additional certificates into the environment to make communication between components more secure, the process of updating these certificates with customers’ own signed certificates has been a challenge.
We are pleased to announce the general availability of vCenter Certificate Automation Tool1.0. This tool provides an automated mechanism to replace certificates in the following components of the vCenter Server 5.1 management platform:
One of the coolest feature in my opinion is Tagging in the new vSphere Web Client. Unlike Custom Attributes which was limited to an ESXi host and Virtual Machine object, the new Tagging capability allows you to create custom labels and metadata on ANY vSphere inventory object. In addition, you can have multiple tags per object and you can search based on tags to help you quickly find what you are looking and making this feature even more powerful. Just like with anything new, it takes time to get used to. To help you use the new Tagging feature, there is a built in Custom Attributes to Tags migration tool in the vSphere Web Client as Tagging will be the future going forward.
The installation of vSphere vCenter Sign-On is a relatively a straight forward process when planned correctly and as there are many factors of the environment that the installation process will touch, it is important to review the vCenter Single Sign-On Server prerequisites prior to deployment, preferably during the initial design phase. It is important to note that the vCenter Single Sign-On server is the first component to be installed prior to vCenter Server install or upgrade.
Before we continue with the pre-requisites and installation of SSO we need to complete the planning of our vSphere install/upgrade design and this includes the desired level of availability required, if any.
When speaking to partners and customers I am often stumbled by the amount of attention and time that is placed on individual SSO availability. My response is bluntly why? followed by the question on what do you use today to protect vCenter server? to which the response is typically nothing or vSphere HA, sometimes vCenter Heartbeat. Don’t get me wrong my background is in business continuity and the way I look at it, SSO is an authentication component of the vCenter server, nothing more, nothing less and so when looking to protect SSO, the solution you choose for protecting vCenter server will provide the best protection of all vCenter components. If you choose not to protect the vCenter server then no protection of SSO is required, if SSO goes down, you bring down the vCenter server management, if only vCenter server goes down, you’re in the same situation, without vCenter server your not going to have much use for an SSO server unless shared with multiple vCenter servers (see below). There are solutions that enable themselves with SSO but these all have a dependency on the vCenter server to be operational. I understand that when reading up on SSO at the excellent vSphere 5.1 Documentation Center, there is a configuration called SSO HA (not to be confused with vSphere HA) and as this is an installable configuration, some believe this is the only option for SSO availability which is not correct. While this solution works, it can be very complex to setup, requires the use of third party technologies but does it give me anymore protection than say vSphere HA? I hope to answer this for you.
There have been some recent questions about upgrading to the latest version of VMware Tools in vSphere 5.1 and the benefits it may bring with future upgrades of VMware Tools. Historically, VMware Tools upgrades has always required an operating system reboot as new device drivers and kernel modules will not go into effect until the next reboot. For Windows operating systems, you could “suppress” a reboot by specifying an advanced installer option. For UNIX/Linux operating systems, the new device drivers and kernel modules will be staged when you upgrade VMware Tools, but will only be activated upon the next reboot. In both case, you can continue to run your virtual machine in a partially upgraded state for a limited amount of time until your next maintenance window, but it is recommended that you reboot as soon as possible.