WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Hybrid environment leveraging SSO Multi-Master Replication between vCenter Server for Windows & VCSA

12.11.2013 by William Lam // 13 Comments

In vSphere 5.5, the SSO (Single-Sign On) component has been completely re-designed to help simplify the management of your SSO Server(s). A built-in automatic multi-master replication architecture is now used to ensure that all SSO instances are always kept in synced. This works great for a pure Windows based environment but what if you wanted to run a hybrid environment that includes a mix of vCenter Server on Windows and the VCSA (vCenter Server Appliance)?

A great use case for this would be for ROBO site management for which you want to simplify the deployment and management of these sites from a centralized location. Instead of deploying additional vCenter Servers on Windows and spend more on Windows licenses, you could leverage the VCSA. With this hybrid model you can still gain all the benefits of having a distributed SSO security domain as well as a centralized place for managing and accessing all your vCenter Servers and Virtual Machines. As you can see from the diagram below, the SSO replication is bi-directional from all SSO instances and this occurs by default every 30seconds. By joining all SSO instances under a common SSO security domain (vsphere.local), you also have the added benefit of being able to see inventory from all SSO instances by logging into anyone of the vSphere Web Clients at each site.

I was recently asked by a couple of VMware colleagues about this particular configuration and whether it would be possible with using the VCSA. It took a couple of days of tinkering in the lab, talking to some folks and several dozen snapshot reverts, but I am please to say I have been successful in getting this to work!

Disclaimer: This configuration is not officially supported by VMware as the configuration has not been officially been tested. Please use at your own risk.

Requirements:

  • Configured Windows vCenter Server
  • Un-configured VCSA deployed

Step 1 - Deploy vCenter Server 5.5 on a Windows server as you normally would.

Step 2 - Deploy a VCSA but do not configure it just yet, we have a script that will automate this for you.

Step 3 - Download configureAdditionalVCSAUsingCommonSSODomain.sh script which will automatically configure the VCSA to point to the external vCenter Server SSO instance as well as setup the SSO multi-master replication configuration. You can either run the script remotely or run it within the VCSA, but before you do you will need to edit the script and modify the following variables.

PRIMARY_VC
VC_USERNAME
VC_PASSWORD
SSO_SITE_NAME

The first three variables pertains to your Windows vCenter Server and make sure the username is *protected email* The SSO Site name can be identified by following the instructions found here. In addition to the above mandatory variables, there are a couple other variables that will automatically join the VCSA to an Windows Active Directory, you just need to enable the flag and fill in the variables.

Step 4 - You are now ready to run the script! The output is a bit verbose, but if you take a look at the script itself is is only a couple of lines 🙂 This is wayyy easier than deploying a Windows OS and then go through all those complex install wizards!

The majority of the script is actually from an earlier script that I wrote during vSphere 5.1 release for the VCSA. However, there are a couple of additions to the script that I would like to highlight. The first is starting all the VMware SSO Services and also ensure it is automatically started up during boot by running the following commands:

/etc/init.d/vmdird start
/sbin/chkconfig vmdird on
/etc/init.d/vmware-sts-idmd start
/sbin/chkconfig vmware-sts-idmd on
/etc/init.d/vmkdcd start
/sbin/chkconfig vmkdcd on
/etc/init.d/vmcad start
/sbin/chkconfig vmcad on

The final part is to configure the replication between the two vmdird instances using the /usr/lib/vmware-vmdir/bin/vdcpromo command. The command requires both the source and target username/password of the SSO administrator account as well as the source SSO Site name which can be identified by following the instructions here.

Once the script has finished (should only take a minute or two) you now can login to either vCenter Server instances and you will be able to see both your vCenter Server on Windows as well as your VCSA.

Note: Currently, the Lookup Service is shared between all vCenter Servers joined to the common SSO security domain. This behavior is not expected and is currently being investigated by engineering. In the meantime, if the primary vCenter Server hosting the Lookup Service is unavailable, you will not be able to login to your other vCenter Servers. You should ensure proper high availability solutions is provided for the vCenter Server hosting the Lookup Service until this issue is resolved.

In just under a couple of minutes you can easily deploy several VCSA's joined to a common SSO security domain with built-in replication and get a "poor" mans Linked Mode to view and manage all your vCenter Servers from a single place.

Note: Even though SSO multi-master replication between VCSA's is not officially supported by VMware, it does in fact work and is something I have been able to setup in my lab. To perform this, you just need to setup you first VCSA as you normally would and using the script above to join additional VCSA to the first one you setup.

In a follow-up blog post, I will show you how to verify SSO multi-master replication is properly configured and replicating using some free online tools.

Categories // Automation, VCSA, vSphere Tags // multi-master replication, sso, VCSA, vcva, vdcpromo, vmdird, vSphere 5.5

Did you know OVF supports a cool feature called Dynamic Disks?

12.02.2013 by William Lam // 7 Comments

A couple of weeks back I had the pleasure of meeting Anders Madsen who is the lead engineer for the very popular and useful tool called ovftool. While having a discussion on a variety of topics with Anders I came to learn about a cool little feature of the OVF specification call Dynamic Disks. This lesser-known feature has actually been around since OVF 1.1 but I suspect that most people have probably not heard of this capability unless you are intimately familiar with the OVF format which I  I know I am not.

When you deploy an OVF you are pretty much deploying a static pre-configured Virtual Appliance that contains a certain amount of cpu, memory and storage. One can easily increase the CPU/Memory of the appliance after provisioning or leverage OVF's Flexible Deployment Options during the deployment of an OVF. On the Storage front it is a bit more difficult since the maximum capacity of each virtual disk is already pre-defined. Similar to CPU/Memory, once the OVF has been deployed you can easily extend the virtual disk(s) but you must also ensure you extend it in the guestOS either manually or automatically using built-in intelligence from the application.

What would be really nice is to have the ability to specify the capacity of a given set of virtual disks during deployment run-time instead of relying on a fixed capacity which is what Dynamic Disks allows you to do. This capability is only applicable for empty virtual disks and does not apply to virtual disks that already contain data such as an operating system or data disk. A great use case for such a feature could be an NFS Server Virtual Appliance where you would have an OS installed on the first virtual disk and then a couple other virtual disks that would be used for the underlying NFS Server volumes. Instead of having a fixed size for the NFS Server Virtual Appliance, it can be dynamically configured during deployment and it is up to the application to have the appropriate logic to handle the setup of the virtual disks during first bootup.

Here is an example of what this would like when deploying an OVF using Dynamic Disks:

You can see from the above screenshot, the OVF I am deploying contains two Dynamic Disks which have a default value of 5GB and 10GB. However, during the deployment I can change these default values to something different.

Instead of of 5GB and 10GB, I decided to change it to 10GB and 15GB and these values will be reflected by the platform that will be used to deploy the OVF whether that is vSphere, Fusion or Workstation. Another great use case for Dynamic Disks is to update the OVF I built to quickly help setup and test VMware VSAN (Virtual SAN) using Nested ESXi. The OVF that I created contains three empty virtual disks: 2GB for ESXi installation, 4GB for virtual SSD and 8GB for mechanical disk. Instead of requiring a user to reconfigure the virtual disks after deployment, you can now specify the capacity you want for each of the virtual disks using the new OVF that I have created here.

I hope to see more Virtual Appliances take advantage of Dynamic Disks capability as it can be useful for providing customized deployment options while still maintaining the notion of a pre-configured system. If you wish to create your own OVF that utilizes Dynamic Disks, please take a look at the instructions below.

Step 1 - Create a Virtual Machine like you normally would that contains both empty and non-empty virtual disks. In the example I have created a VM in vSphere which contains one virtual disk which would contain an OS (in this example its just empty) and two additional virtual disks (disk 2 and 3) which will be used for Dynamic Disks.

Step 2 - Export the VM to an OVF and delete the virtual disks files that will be used as Dynamic Disks as well as the OVF Manifest file as the contents will change.

Step 3 - Next we will need to make a couple of edits to the OVF descriptor file and the first change is to delete the virtual disks reference entries that will be used for Dynamic Disks. In this example that will be disk2 and disk3 as seen in the screenshot below.

Step 4 - We now need to delete the fileRef property for our two virtual disks located in DiskSection which is usually located at the top of the file. We also need to modify the capacity values into variables that will be used within the OVF file. You can select any name you want for the variable and in this example I chose ${disk1size} and ${disk2size}.

Step 5 - Finally, you need to add two new property entries which is embedded in the ProductionSection of the OVF descriptor and usually located towards the bottom of the file. Also make sure this sits under the VirtualHardwareSection but before the VirtualSystem tag as seen in the screenshot below.

    <ProductSection>
      <Info>Information about the installed software</Info>
      <Product>NFS Server</Product>
      <Vendor>virtuallyGhetto</Vendor>
      <Version>1.0</Version>
      <Property ovf:key="disk1size"
            ovf:runtimeConfigurable="false"    
            ovf:type="int"
            ovf:qualifiers="MinValue(1) MaxValue(10000)"
            ovf:value="5"
            ovf:userConfigurable="true">
        <Label>NFS Datastore Size for Disk 1</Label>
        <Description>The size of the disk in gigabytes.</Description>
      </Property>
      <Property ovf:key="disk2size"
            ovf:runtimeConfigurable="false"
            ovf:type="int"
            ovf:qualifiers="MinValue(1) MaxValue(10000)"
            ovf:value="10"
            ovf:userConfigurable="true">
        <Label>NFS Datastore Size for Disk 2</Label>
        <Description>The size of the disk in gigabytes.</Description>
      </Property>
    </ProductSection>

The two disk variables that we defined earlier is used in this section that allows you to specify a default value as well as some additional text that can be displayed for each property. Instead of having you copy/paste from the blog I have provided a sample OVF that consumes Dynamic Disks in which you can use as an example for creating your own. To use this OVF you will need to download the following two files and then import into your environment:

Dynamic-NFS-Server.ovf
Dynamic-NFS-Server-disk1.vmdk

Once you have made all the necessary changes, you can then deploy the new OVF and the OVF wizard should now detect that Dynamic Disks are being used and you should see a message similar to the one below.

Categories // Automation, OVFTool, vSphere Tags // dynamic disks, ovf

SPBM (Storage Policy Based Management) MOB in vSphere 5.5

11.27.2013 by William Lam // 8 Comments

A handy little tool that was useful for me which might come in handy for others too while working on my VSAN VM Storage Policy recovery article is the SPBM (Storage Policy Based Management) MOB which works similar to the vSphere MOB and FDM MOB for those of you who have used this interface before. The MOB stands for Managed Object Browser and simply put is an interface that allows you to browse the objects and properties of your vSphere environment by just using a web browser. You can also interact with the MOB by executing the same set of vSphere API methods as you would if you were to write a script or application which is useful for quickly getting a sense of what a certain property might look like or the output of an API method without writing a single line of code.

In vSphere 5.5, there is now an SPBM API which is available as a separate API endpoint on the vCenter Server. This new API allows you to manage the full lifecycle of a VM Storage Policy formally known as VM Storage Profiles from a programmatic standpoint which is very important when working with VSAN as everything is policy driven. For more more details about the new SPBM API, please take a look here. As mentioned earlier, one great way to learn about the API is by exploring the MOB and luckily the SPBM API includes one!

To access the SPBM MOB in vSphere 5.5, you will need to point your browser to your vCenter Server as that is where the endpoint is exposed using the following URL format:

http://[VC-IP-OR-HOSTNAME]:8190/mob

To access the SPBM MOB in vSphere 6.0, you will need to point your browser to your vCenter Server as that is where the endpoint is exposed using the following URL format:

http://[VC-IP-OR-HOSTNAME]/pbm/mob

You will be prompted for your vCenter Server credentials before the MOB will allow you to login. Once you are logged in you will be brought to the main service content of the SPBM endpoint similar to the vCenter Server service content and you can then click on content link to explore the various sub-managers that are available.
Note: You will be able to get more details on each of these sub-managers by taking a look at the VM Storage Policy Programming Guide and VM Storage Policy API reference guide.
To quickly show you around, I will provide a couple of examples using the ProfileManager and I am sure you can probably guess what type of functionality it provides :). The first method that we will take a look at is the PbmQueryProfile which will return the list of available VM Storage Policies that have been defined. You will need to set the resourceType property to "STORAGE" and remove the profileCategory and then click on "Invoke Method".
If you are using VSAN and you do not have any VM Storage Policies defined, there will still be two default VM Storage Policies that is automatically created when VSAN is enabled. What you will see are the internal identifiers for each of the VM Storage Policy and as you can see from the output I have 5 VM Storage Policies.
You will notice that the output does not contain the human readable display name for each VM Storage Policy, to retrieve that information we will need to use the PbmRetrieveContent which accepts a list of VM Storage Profile ID's and in return provide the human readable name as well as other properties such as the initial creation date and last modified date. Using the pre-canned input form, you can specify one or more VM Storage Profile IDs from the previous step and then click on "Invoke Method".
In my example, I specified two of my VM Storage Policies and I can see they map to the names  "Aluminum" and "Copper" which is what I named them when I first created the policies.
From here on out, we will be using the VM Storage Policy ID as that is what is used to uniquely identify a VM Storage Policy and input for majority of the SPBM API methods. Now if we want to see what objects (VM Home directory or VMDKs) are associated with a particular VM Storage Policy we can use the PbmQueryAssociatedEntity method. You will need to provide the VM Storage Policy ID and remove the entityType and then click on the "Invoke Method".
As you can see from the output this a virtualMachine object type which tells us this VM Storage Policy is used for the VM Home. Lets go ahead and specify a VM Storage Policy that is used for a Virtual Machine's VMDK and see what that looks like.
We now see the object type is virtualDiskId and you can see the particular VMDK and the associated Virtual Machine by looking at the key which has the format of vm-mo-ref:vmdk-key. Now what if we wanted to perform the reverse look up, by providing only a Virtual Machine or VMDK as input? Well, we can easily do this lookup by using the PbmQueryAssociatedProfiles method. This API method requires you to specify three parameters: objectType, key and serverUuid (technically speaking the serverUuid can be left out).
From the above examples you will get an idea of what the expected input format is for either a Virtual Machine or VMDK query.
Here is an example of a Virtual Machine query:
Here is an example of a VMDK query:
Hopefully this quick introduction of the SPBM MOB will give you a good idea on how you can leverage this interface, especially if you plan on using the new SPBM API to automate and manage your VM Storage Policies.

Categories // Automation, VSAN, vSphere 6.0 Tags // ESXi 5.5, mob, spbm, Storage Policy Based Management, vm storage policy, vm storage profile, vSphere 5.5

  • « Previous Page
  • 1
  • …
  • 207
  • 208
  • 209
  • 210
  • 211
  • …
  • 224
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Ultimate Lab Resource for VCF 9.0 06/25/2025
  • VMware Cloud Foundation (VCF) on ASUS NUC 15 Pro (Cyber Canyon) 06/25/2025
  • VMware Cloud Foundation (VCF) on Minisforum MS-A2 06/25/2025
  • VCF 9.0 Offline Depot using Synology 06/25/2025
  • Deploying VCF 9.0 on a single ESXi host? 06/24/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025