Many admins are either implementing or considering the VMware Virtual SAN, to dive more fully into the software-defined storage space. After having spent time there myself, I wanted to share a tip. You know that it's important to check out the VMware Compatibility Guide when shopping for components. But just as important as compatibility is performance.
The good news is that the Guide now includes information for controllers and drives (both solid state and rotational drives) that are supported for use with VMware Virtual SAN. Figure 1 shows the new compatibility guide.
This is important for both lab and production environments. Pay particular attention to the solid state drive (SSD) component of the Virtual SAN, if you're using those. Although SSDs not in the compatibility guide may work, their performance may surprise you – by being even worse than Hard Disk Drives (HDDs).
I can say from direct experience that I've run ESXi hosts with unlisted SSDs, and they were actually slower than the regular hard drive I'd used previously. Thus, if you're using unsupported devices with Virtual SAN, you likely won't get a sense of how well it works.
As you may know, Virtual SAN uses both SSDs and HDDs to virtualize the storage available to run virtual machines (VMs). When you decide to add SSDs, consider PCI-Express SSDs. That allows you to use a traditional server with HDDs in the normal enclosure (and the highest number of drives), then add the SSDs via a PCI-Express card.
The PCI-Express interface also has the advantage of higher throughput, as compared to sharing the SAS or SATA backplane, as is done with HDDs. I've used the Micron RealSSD series of PCI-Express drives within an ESXi host (Figure 2); what's great is the performance delivered by these and other enterprise SSDs. They can hit 30,000-plus writes per second, which is the Class E tier on the compatibility guide. This underscores an important point to remember when researching storage: all SSDs are not created equal!
Have you given much thought to the SSD device selection process with vSphere and Virtual SAN? What tips can you share? What have you learned along the way? Share your comments below.
Posted by Rick Vanover on 01/12/2015 at 11:01 AM0 comments
The message from vSphere Client when I try to perform a task that can't be done in the Windows Client is a quick reminder of a few things. First of all, I need to use the vSphere Web Client more. Second, I need to know, going in, which tasks can be done in which administrative interface for day-to-day work. The message I'm referring to is shown in Figure 1.
The rule for now is that full VM administration for hardware version 8 can be done in the Windows vSphere Client (the C# client). The vSphere Web Client enables full administration of hardware version 10 VMs.
But what if there's a mix of hardware version 8 and 10 VMs? Let's assume that both the vSphere Web Client and vSphere Client are in use. What tasks can't be performed in the vSphere Client on hardware version 10 VMs? Here's a list of some of the most notable ones:
- Edit virtual machine settings
- Edit resource allocation (e.g., CPU, memory limits)
- Manage storage profiles
- Export a VM as an Open Virtualization Format (OVF) template
- Configure hardware version 10-specific features, including: virtual machine disks (VMDKs) larger than 2 TB; Virtual SAN; input/output operations per second (IOP) limits for VMs; vSphere Tags; vSphere Flash Read Cache
The inability to edit VM settings is the big one. That means not adding VMDKs, CPU or memory, among other drawbacks. I've long used the vSphere permissions model to let application owners use the vSphere Client to do day-to-day administration of their VMs; this is a practice ripe for a refresher with the vSphere Web Client. A temporary reprieve has been granted since the vSphere Client will be around for the next version of vSphere; still, it's the right time to move all substantive administrative tasks to the vSphere Web Client.
An important takeaway is that when the vSphere Client is used on newer hardware versions, the core administrative tasks can still be performed, including:
- Power on/Power off
- Open console
- Alarm management
- Deploy VM template
- Permissions assignment
- Display performance and storage views
You can see in Figure 2 that the Web Client UI has all the functionality you need.
Have you found any other core day-to-day stopping points where you can't do certain things with hardware version 10 VMs in the vSphere Web Client? If so, what was it? Share your situation in the comments.
Posted by Rick Vanover on 12/19/2014 at 8:19 AM0 comments
vSphere 5.1 raised the maximum virtual machine (VM) size to 62TB. There is a catch, however: hardware version 10, along with the vSphere Web Client, must be used. That's OK, because I'm convinced the benefits outweigh any issues with day-to-day administration. I believe the 62TB Virtual Machine Disk (VMDK) is the best way to avoid any bad habits that may have been developed over the years for VMs that needed more than 2TB of space.
The large virtual disk format is primarily a safeguard; it keeps admins from doing bad things to good vSphere environments. When I say bad things, I primarily mean storage configurations that don't make sense anymore for VMs. I see five key reasons to use the large disk format in a vSphere environment:
1. No More RDMs. Raw device mappings (RDMs) are used to directly present block devices to VMs. This is done primarily to ensure that application configurations, such as clustering with two VMs, can be done within vSphere. It basically means shoehorning a physical application design into a virtualization layer.
There's also a thought that RDMs perform better than VMDKs. The reality is that the performance difference is trivial -- at best -- today, given the latest improvements and designs.
Furthermore, RDMs complicate everything. You can't easily move these VMs to new hosts, and they can cause issues when using the vSphere APIs for Data Protection.
2. Better iSCSI Management. I remember a time when, to attach an iSCSI LUN, I would just create a VM and run the iSCSI initiator inside the guest VM. That seemed like a great way to avoid the 2TB virtual disk format limit -- that is, until I needed to move the VM's storage. Using the 62TB VMDK allows a VM to be fully contained in the vSphere environment, simplifying things; using iSCSI in the VM only complicates the VM's portability.
The End of Dynamic Disks. If the first two options aren't used, dynamic disks can deliver more than 2TB on a single guest OS volume. But they're generally a weak solution. I don't use the Windows dynamic disks much; they have legendary issues when something goes wrong. Additionally, there are some interesting performance considerations if multiple VMDKs are part of the same dynamic disk set, but are on different datastores with variable performance. I like simple. Large VMDK files can provide the needed size, yet still be in the simplest configuration within Windows. This saves time and troubleshooting later on.
4. The Benefits of Thin Provisioning. Thin provisioning of virtual disks allocates a maximum size (up to 62TB), but only uses what a VM will put on it. For example, if I create a VM with Windows Server 2012 on it, I can specify a 62TB VMDK. It starts at just 8GB for a base installation, however, freeing up space elsewhere.
Thin provisioning is a good safeguard for times when the size of the VM grows beyond a common threshold, such as 2TB. You can dynamically expand virtual disks, but if more than 2TB, the VM may need to be powered off and upgraded to VM hardware version 10. I recommend switching to using large disks, so that a VM with an expanding storage requirement won't be stopped in a disruptive manner. Figure 1 shows a 62TB VMDK in the vSphere Web Client.
A natural objection to letting all VMs have as much room as they need is the danger of running out of disk space. That's indeed a risk; I'll cover it in a future blog posting.
5. Less Complicated VMs. I deal with a lot of different people in a lot of different situations; they're all in various places in their virtualization journey. Every now and then I'll get a question about a VM, and it's been configured with something like 12 virtual disks. I cringe in those situations, as I prefer a simple configuration from the infrastructure perspective. If there's one really complicated VM, let the VM be complicated within the OS; don't make a pretty infrastructure ugly and more difficult to manage with one VM that sticks out like a sore thumb.
For these five reasons, I'm encouraging you to use the latest and greatest configuration techniques on all your vSphere VMs. In particular, the 62TB VMDK along with the VM hardware version 10 are the latest advances in the specific VM configuration options that can prevent problems down the road. Have you replaced a bad storage habit with the 62TB VMDK? If so, share your experiences below.
Posted by Rick Vanover on 12/10/2014 at 11:41 AM0 comments
Early in my virtualization career, VMware vCenter Converter was one of the first tools that helped me get started with building a virtualized data center. Converter is a physical-to-virtual (P2V) tool that converts physical servers to virtual machines for us in vSphere environments. My days of using Converter on a daily basis are over, but I still do use it.
And every so often, there are updates to Converter that bring interesting new features (or deleted capabilities). Because of that, it's important to know what's going on with this tool. The standalone version of Converter is now at version 5.5.3, and it has a few points of interest I wanted to pass along. You can, of course, read the whole user guide or release notes, but I prefer a short and sweet summary of the key changes:
- The big "What's New" is OpenSSL update. You may want to forget about the Heartbleed bug, but if you're using an older version of Converter, this fix alone should be reason enough to update. It protects you against OpenSSL security vulnerabilities, including Heartbleed.
- No support for Windows 2000 systems. This isn't new or specific to the latest release, but don't think that Converter will save the day for a VM or obsolete server that's been ignored forever, since Converter 5.5.3 can't convert Windows 2000 servers. Windows 2000 and NT system support was discontinued in Converter 4.3, meaning that Converter 4.0.1 is the last build to include 2000 and NT support. I'm not encouraging you to keep these operating systems, but if you need to move them, Converter 4.0.1 may still be worth having.
- VMware Server removed. There was a time that I used VMware Server 2.0 for almost everything. That was before ESXi and a critical change in my data center practice. VMware Server was popular for small environments, but has been dead since 2009 in VMware talk. VMware Server is not a supported source VM for the newest Converter. Note that VMware Workstation 7, 8, 9 and 10 are supported, as are VMware Player 3, 4, 5 and 6.
- Windows Server 2012 R2, Not R2. In the documentation, only "Windows Server 2012" is listed as a supported operating system. It doesn't specify R2, which is strange, as R2 is likely to be the default version of Windows Server 2012 for most. Its absence as a listed system doesn't mean it won't work, but it's something to be aware of. By way of convention, both Server 2008 and 2003 have their "R2" designations separate. Read the release notes if you'd like to verify this for yourself.
- Converter 5.5 keeps up with ESXi 5.5 and vCenter Server 5.5. Try to use the latest version of Converter in all situations. And whatever you do, don't use the same version of Converter from five years ago with your shiny new vSphere cluster. Newer vSphere editions may work with older versions of Converter, but drives and VM inventories may not be built as expected, especially if newer features like VMFS-5 volumes or VMware Virtual SAN are in use.
- VMware Virtual SAN supported. Again, it's not a new feature for 5.5.3, but in the area of Virtual SAN, be aware that Converter 5.5.1 had introduced support for the new storage option with vSphere.
Converter may not be the coolest part of my virtualization practice nowadays, but when I need some help it has always been there for me. I do my best to check back on it often, since it doesn't get the promotion that the other mainstream products get; but I don't want to ever be in a situation to find out that a capability I had before is no longer available.
Do you still use Converter? If so, how do you use it? Share your use cases and comments on the latest features below.
Posted by Rick Vanover on 12/03/2014 at 11:08 AM0 comments
I've recently been working a lot within the big cloud platforms. As I've checked them out, I've realized that they may be the best way to truly scale high-performance storage. Specifically, I'm very much liking what I see with the SSD-Accelerated Storage available in vCloud Air.
The SSD-Accelerated storage option in vCloud Air is loosely based on vSphere Flash Read Cache, a vSphere 5.5 feature that makes it easy to use Solid State Drives (SSDs) in vSphere environments. The vSphere Flash Read Cache is just an acceleration technique for reads, but it can still bring performance benefits that may be just what you need for certain application I/O demands.
So, why do I find this so interesting on vCloud Air? Well, consider the scalability compared to the cost. In particular, note that scalability includes the expansion use case as well as contraction. vCloud Air (as do other cloud platforms) are built to scale well, and downward provisioning is a good use case here.
Compare the in-house model where there is a project or short-term use case where high-performance storage would make sense. In some situations, even virtualized environments may have to purchase some equipment to address this need. The issue is that it may be underutilized after the project is over, limiting the return on investment. Consider the vCloud Air pricing for SSD-Accelerated Storage shown in Figure 1.
While SSD-Accelerated Storage is an innovative way to use SSDs, it's not the only option: There are a number of ways today to leverage non-rotational storage for higher performance, and there's no one-size-fits-all solution. Everything from memory acceleration, flash or SSD acceleration, tiered storage, all-flash arrays and many hybrid options exist today.
Will vCloud Air be the burst of high-performance storage that you need, when you need it (and, of course, removed when you don't need it)? Possibly. I've been using it a bit and so far have liked what I've seen. What's your take on vCloud Air and the SSD-Accelerated Storage? Share your comments below.
Posted by Rick Vanover on 11/18/2014 at 8:14 AM0 comments
If you haven't given a good look at the VMware vCenter Server Appliance (vCSA) since version 5.5, it's time to do so. The vCSA has a good use case and increased scale compared to previous editions. I've been using it in both production and lab environments, and I wanted to take a look at one feature in particular: Automatic Updates.
I've given a lot of thought to the update process for my vSphere environment. In the early days of my virtualization work, I was very standoffish about updating in general. As I became more comfortable -- regarding infrastructure supportability, in particular -- I was much more willing to update. The update process is different than the upgrade process, which installs major versions. vSphere Update Manager makes easy work of the process, and continues to make it easier for vSphere administrators to keep the components both updated and upgraded.
The job of vCSA is to host the vCenter Server application, and that application needs to be updated occasionally. The good thing about the appliance is that it's quite easy to do with new (since vSphere 5.5) Automatic Updates. The Automatic Updates feature is configured in the administration page (5480 port interface) of the vCSA, as shown in Figure 1.
As a safety feature, once updates are retrieved, the vCSA has to be rebooted. This is a good safeguard, as you wouldn't want to have a high availability (HA) event or Distributed Resource Scheduler (DRS) rules not perform as expected. When Automatic Updates has an update that needs to be installed, you simply reboot the vCSA. You'll see a message similar to Figure 2
when you have an update eligible for installation.
Upon the subsequent boot, the vCSA will have the newer build and be updated. If you're using the vSphere Client (Windows application), you may need to update that, as well. This is a pretty seamless way to update the vCSA, and has served me well thus far. Are you using the Automatic Updates feature? If so, how has it worked out for you? Let me know in the comments.
Posted by Rick Vanover on 10/31/2014 at 11:27 AM0 comments
I talk to a lot of vSphere administrators today who use a number of different deployment techniques. Some are sticking with templates, as they have for years, but some also have moved to newer deployment techniques. One of the fashionable approaches right now includes using Windows Deployment Services (WDS), which is a PXE-boot mechanism. And there are also VM clones.
I don't always have a recommendation on what's best. I'm skipping over the use case of vCloud Director libraries or vCloud Automation Center workflows; but determining what's the best new VM deployment approach really depends on the target environment.
Personally, when I'm in my lab environments, I find that clones and WDS work really well. Their deployment processes easily accommodate the one-offs that make up the normal behavior of a lab. Additionally, customization specifications used in templates can be used in cloned VMs.
Deploying a template (with or without a customization specification) is very similar to deploying a clone. The big difference is whether or not the customizations kick in and provide specifics like operating system product keys (in the Windows use case). WDS works pretty good for labs as well, but has a few more manual steps. It's rather quick, but not quite as quick as a clone or template. The clone task for a VM is a right-click on a VM in the vSphere Web Client:
WDS does well with a good healthy mix of vSphere and Hyper-V, as well as some physical servers. It can use the same mechanism for all platforms, which is good for consistency.
Believe it or not, plenty of people still do entire builds of new VMs by hand. This is typically a smaller organization that doesn't need a template because new VMs aren't constantly being built. For production environments, I prefer templates with the customization specifications that apply to a particular production VM. The main difference between cloning a VM and deploying a template is that the template can't be powered on, and therefore can't have configuration drift.
How do you deploy VMs from production and lab environments? Do you do it differently for production, lab or test environments? How so? Share your comments below.
Posted by Rick Vanover on 09/30/2014 at 11:33 AM0 comments
I was recently in a discussion with a group of vSphere administrators about a
particular lab environment, and we were upset that some of the Tier-1 storage
was being used for workloads that weren't quite appropriate for the use case.
Lab environment or not, many vSphere administrators have extended some
permissions to persons outside their group. A good example in my professional
experience was assigning permissions to application administrators for key
features such as remote console and the power button functions of supported VMs.
This saved me work and let them serve their application better, even if I
thought it was maybe a bit finicky.
When it comes to provisioning VMs from a storage perspective, it's a race to the
most precious resource in the data center. I'd go so far as to say that the new
"server under the desk" phenomenon -- an age-old problem taking on a new shape
-- is now VMs residing where they shouldn't. To protect the most critical
vSphere resource (the VM storage), I recently revisited the
datastore permissions construct to solve the problem of ensuring that the wrong VMs
don't end up in that precious Tier-1 storage.
Datastore permissions aren't absolute -- they
apply to the vCenter Server application and below. They don't apply to the
storage fabric. But for the bulk of what we do, this solves the problem of
keeping the right VMs in the right places. The vSphere permissions for the
datastores are set on the "Manage" tab of the vSphere Web Client, as shown in
The figure shows that I'm applying specific users and groups for access to an
SSD drive. For those holdouts who refuse to use the vSphere Web Client, the
Windows Client can address datastore permissions. The permissions tab will do
the trick there.
Datastores aren't the only permissions-based
vCenter objects, as you may know. Others include folders, resource pools, vApps
and so on. Do you use the permissions model (and any corresponding roles) for
any complex implementations? If so, how have you built your permissions? Do you
use this outside of vCloud Automation Center (vCAC)? Share your strategies
Posted by Rick Vanover on 08/19/2014 at 1:38 PM0 comments
The recent vSphere releases are placing more emphasis on the vSphere Web Client, yet many vSphere administrators have been dragging their feet on the transition. I'll even admit to that -- I had set a goal that I'd use the vSphere Web Client almost exclusively for all admin tasks, but haven't always achieved that goal. Still, I wanted to share some things that have helped me. Hopefully, they can help aid your transition to the new administrative interface:
- Use hardware version 10 VMs and the 62TB VMware Virtual Disk File (VMDK). This is tricky: if you put a VM on hardware version 10, you're required to use the vSphere Web Client for core administrative tasks, such as editing the hardware. Power actions and console access are still available from the Windows client, however.
Don't miss out on this new feature (the 62TB VMDK) because you're not using the newest administration interface. It's a good practice to avoid the crazy workarounds for the 2TB drive limitations some admins have implemented. This includes in-guest iSCSI, VMs with a large number of VMDKs and unnecessary Raw Device Mappings (RDMs).
- Use automation. Do you find yourself using the Windows client because it's quicker to navigate than the vSphere Web Client? You don't have to -- many tasks can even be faster if you automate them. PowerCLI is the vSphere PowerShell extension, and can really save you time. To help get started, check this recent post on the PowerCLI blog; it shows how to set VMs to update VMware Tools at PowerCycle (tip No. 2). Investments in automation always pay off.
- Use vSphere Tags. The vSphere Tag is a new-ish way to apply metadata to an object in vSphere. This is a great way to search across many different locations for objects: Tier 1 vs. Tier 2, production vs. dev, PCI vs. non-PCI ... you name it. It's a non-infrastructure focused organizational construct, and is different than the vApps, Folders, Resource Pools and so on that we've used thus far.
- Use the search tool. At the very top right of the vSphere Web Client is a search field. What does it do? Well, it searches across all objects or results. Chances are, this search is actually quicker on the vSphere Web Client than the Windows client. It is for me.
The search is a very quick way to jump to an object of any type without using the navigation tree. If you need to manage a datastore, then a VM, then a virtual switch, just type in part of the name; the objects that meet the criteria will show up quickly.
- Unlock the power of the Actions button. If you're like me, the hardest part sometimes is just finding where to do something. The right-click Actions menu is the place you'll often want to go. This was a big ease-of-use point for me:
The transition to the vSphere Web Client is a process, one that takes time. But chances are you've found steps along the way to help you get what you need. Do you have a tip to share about the vSphere Web Client? Share it below.
Posted by Rick Vanover on 08/05/2014 at 6:37 AM0 comments
I had a situation recently discussing a configuration with a client where they preferred to not deploy a particular workload as a virtual machine. Their logic was actually quite sound in the process; a few of their points are outlined as follows:
- They were high experts on the application and they can redeploy it easily.
- The application required a lot of CPU and RAM resources, and they wanted to avoid that impact on their cluster.
- The application has a clustering feature.
- The costs were effectively indifferent.
The process they went through was thorough, and it didn't involve some of the frequent reasons that people decide not to virtualize. Those are usually licensing, vendor support or plain fear of the unknown. The important thing to note on this situation is that while they didn't quite hit 100-percent virtual in their data center (they were in the high 90s in terms of systems virtualized) they met all of the requirements for availability and management.
A lot of us have embarked on the virtualization journey for benefits such as increased availability, cost savings, better utilization and increased management. If you can meet these key initiatives without using virtualization, it's not entirely taboo to pass on leveraging virtualization.
This certainly wasn't a unique situation. I'm sure all of us have been there in some form. In fact, in my professional virtualization practice I still have certain scenarios where I recommend certain systems and components to be physical when a fully separate cluster isn't an option. A good example of this is the vCenter Server system. I've installed the vCenter Server that manages a production cluster in a VM that is on the development cluster. It's also important to make sure that VM runs on a separate network, SAN and possibly even a separate location.
In the situation I had where it didn't make sense to virtualize the application, there was a clear preference to virtualize the rest of the data center. So much so, that for all other systems it is a requirement that it be deployed as a VM. That's generally my preference as well, as I'm sure is yours.
What situations have you avoided virtualizing systems? What is your logic in the process? Share your comments here.
Posted by Rick Vanover on 10/09/2013 at 3:27 PM0 comments
The appliance model is here to stay and when done correctly, it works well. That's the case with the vCenter Server Appliance, which I've been using for a while in various capacities, including some production-class clusters. And I've learned a few things along the way.
If you are like me and are familiar with using the Windows version of the vCenter Server application, then this is for you! Here's a 10-step program to setting up the vCSA:
- Deploy the vCenter Server Appliance -- Download the OVF and deploy it locally. Don't try to pull it from the Internet. Besides, if you need to do it again (in case you mess something up, for example), you'll have it locally.
- Give the vCSA a name and set DNS -- One thing we always keep learning about VMware is that DNS needs to be correct. The vCSA doesn't change that. So take the time before you do anything to set the DNS server settings for the vCSA and give it a name. It's important to NOT let it go on any further thinking it is "localhost". You do this in the Network section, address tab (see Fig. 1).
Figure 1. Set DNS and name before doing anything else with the vCSA. (Click image to view larger version.)
- Restart vCSA -- This will get DNS and naming correct on the vCSA.
- Join Active Directory-- If you so desire to add vCSA to Active Directory and use groups and users already setup there, this will allow subsequent settings (such as vCenter Single Sign On) to go much easier later. Better to do this step now.
- Reboot vCSA -- While reboots are boring, your chances of success will increase greatly by rebooting at this point.
- Check configuration -- This is an easy step, but it is very important. Ensure that everything points to the vCSA being the name you set it in step 2. This includes external pings, nslookups, etc. If you need to add any static DNS A records, now is the time.
- Run vCenter Setup -- Inside the Web UI of the vCSA is a button to launch the setup wizard (see Fig. 2). If you are like me, you've run this as step #1 or #2, and chances are some things just didn't work as expected. Run this as one of the last steps.
Figure 2. The setup wizard will configure the vCenter Server application on the appliance. (Click image to view larger version.)
- Add the domain as an identity source in SSO Configuration -- If you are using Active Directory, you should get the domain as an identity source, to then enable permissions assignment.
- Assign permissions -- Once step #8 is done, you can add Active Directory users and/or groups to the ___Administrators____ group in SSO's System Domain so that vCenter logins can happen easily with Active Directory logins.
- Build a cluster!
At this point, this appliance will work very well for you and weird issues that you may have experienced along the way should be made easier. In particular, certificates that always mention "localhost" and Active Directory not working as expected may behave better.
What tips do you have to set up the vCenter Server Appliance? Share your comments below.
Posted by Rick Vanover on 09/25/2013 at 3:28 PM0 comments
If you are like me, you may find that it is a little bit more difficult to "self-teach" yourself some of the new things for VMware technologies. This applies to VMware vCloud Director and also some of the underlying components of the VMware Software-Defined Datacenter. One of those components is vCenter Single Sign On.
Before I show my representation of how I am using it in my virtualization practice, I should first explain why it is necessary. I'm sure you (like me) had a bit of learning curve during the upgrade from vCenter 5 to 5.1, where vCenter Single Sign On was introduced. Why was it introduced? Many people would say I already have a unified identity management in Active Directory.
Let's look at the big picture of the VMware Software-Defined Datacenter. It includes things like vCloud Director. vCloud Director, in the largest use case, will talk to many different organizations. When that comes into play, multiple Active Directory domains across organizations are going to be a mess for native trusts and such. vCenter Single Sign On provides a great way to broker that.
But even for the small organization vCenter Single Sign On, vCloud Director and the rest of the components can find a fit and indeed use Active Directory. So when it comes to a product, like vCloud Director, vCenter Single Sign On was made out of necessity to cover every use case.
Aside from that, let's break down how it works. So there are a few constructs in play, I think now is a great time for a diagram (see Fig . 1).
Figure 1. The vCenter Single Sign On engine connects core components like vCenter to external sources like Active Directory. (Click image to view larger version.)
That seems easy enough, but the vCenter Single Sign on engine is actually very robust. Remember the big vision of the VMware Software-Defined Datacenter; there are a lot of components to that. I think I counted 11 in the vCloud Suite. vCenter SSO is the conduit between them all. But for my virtualization practice, I still need only Active Directory, so I simply add it as an external source to the vCenter Single Sign On (see Fig. 2).
Figure 2. One Active Directory domain, SSA, is added as an external source. (Click image to view larger version.)
Then you can add groups to the "__Administrators__" group in products like vCenter Server and assign roles accordingly. Yes, it is different than previous implementations and works well with the appliance model. I'll avoid taking votes on whether or not everyone likes appliances.
Now, this is a good big picture, but you will need more information to understand vCenter Single Sign On. No worries, VMware is already on it. Here are two of the best resources I've been using in my labs. The first is a blog post from VMware, vCenter Single Sign-On Part 1: what is vCenter Single Sign-On? The second is from the vCenter documentation, Understanding vCenter Single Sign On. Have you used vCenter Single Sign On yet? If so, what have you learned along the way? Share your comments here.
Posted by Rick Vanover on 09/17/2013 at 3:29 PM0 comments