It was recently pointed out to me that Part 2 of my DHCP on an ESG post didn’t happen… so 15 months later than planned… this is how we configure DHCP relay on a DLR!!
To configure DHCP Relay on a Distributed Logical Router, go to the ‘Networking and Security’ pane in the vSphere web client, then go to ‘NSX Edges’ and double click on the DLR instance you wish to configure DHCP Relay on. Select Manage > DHCP Relay:
All credit for this post belongs to one of my colleagues called Imran Mughal, a very talented vSphere engineer!
We recently came across an issue during some site migration work on our PSC’s. The scenario which drove our PSC site migration work was the fact that we noticed all of our vCenter Servers were trying to authenticate users via a single load balanced pair of PSCs regardless of physical location instead of the PSCs in the datacentre local to the vCenter. This was due to us only using a single site name that covered 4 separate datacentre locations. All of our PSCs regardless of which physical location formed part of this single site.
As we already had live service running on out vCenters we decided to re-direct vCenters to another PSCs and rebuild in pairs (as there is currently no way to manually change the site name or create new sites over an existing deployment).
This was done using a combination of these two KB articles:
KB2131191 & KB2113917
Big thank you to all the people who have helped and encouraged me, especially my gorgeous fiancé Aileen Stewart putting up with me working on my lab or writing blog posts (and occasionally coming home late after one too many vBeers!)
It really is a huge honour to be recognised and great that I get to work with a technology that excites me every day!
Thank you so much!
Came accross this recently, when working with vCO and launching the Orchestrator Web Client you get the error message below:
You need to ensure the “weboperator” is published. To do this log into the vCO client as an administrator and change the focus drop down to “Administrator” then select “Web Views”, “weboperator” and click the Publish button (the green start button).
Forgive a little self indulgance… I was recently featured in an article by Duncan Epping no less!!
Platform Service Controller replication can be setup in multiple ways, when I ran through a test configuration of 4 sites, each with a single PSC. I was wondering how replication would be automatically configured out of the box. When I installed the PSCs I used the previously configured PSC to configure the newly built PSC:
PSC1 (Built First) <—- PSC2 (built second) <—- PSC3 (built third) <—- PSC4 (built fourth)
The following commands allowed me to view the replication configuration and then setup a topology of my choice:
vdcrepadmin -f showservers -h FQDN_of_Local_PSC -u administrator -w password
What is Platform Services Controller 6.0 (PSC)?
The Platform Services Controller (PSC) is a component of the vSphere Suite. The PSC deals with identity management for administrators and applications that interact with the vSphere platform.
What are the key capabilities of PSC 6.0?
- PSC 6.0 remains a multi-master model, as was introduced in vSphere 5.5 in the form of vCenter Single Sign-On.
- It can be deployed either in an Appliance-based or Windows-based flavor, both able to participate in multi-master replication also both Appliance-based or Windows-based PSCs can interoperate with Appliance-based or Windows-based vCenter Servers.
- It can handle the storing and generation of the SSL certificates within your vSphere environment.
- It handles the storing and replication of your VMware License Keys
- It handles the storing and replication of your permissions via the Global Permissions layer.
- It handles the storing and replication of your Tags and Categories.
- It has a built-in feature for automatic replication between different, logical SSO sites.
- There is only one single default domain for the identity sources.
What are the components that are installed with Platform Services Controller 6.0?
Components that are installed with PSC 6.0 include:
- VMware Appliance Management Service (only in Appliance-based PSC)
- VMware License Service
- VMware Component Manager
- VMware Identity Management Service
- VMware HTTP Reverse Proxy
- VMware Service Control Agent
- VMware Security Token Service
- VMware Common Logging Service
- VMware Syslog Health Service
- VMware Authentication Framework
- VMware Certificate Service
- VMware Directory Service
After searching around and not finding anything that covers the entire string, I figured I’d throw in what information I have. I like to label my datastores with my source information, which makes it easy to search and isolate when SAN work has to be performed. The labels make it easy, but I’m relying on information gathered to create these labels. So, this is a way, if nothing else, to validate that the information is being applied to the correct identifier.
vCenter Server with Embedded PSC and Database
The embedded PSC is meant for standalone sites where vCenter Server will be the only SSO integrated solution. In this case replication to another PSC should not be required and is not possible.
- Device is a single point of failure.
- Supports Windows and VCSA (vCenter Server Appliance) based deployments
- Replication between PSCs not required
- Multiple standalone instances supported
- Sufficient for small scale deployments
- Not suitable for use with other VMware products (vRA, NSX etc.)
- Easy to deploy and maintain
Recently I added an ESXi host to a VSAN cluster (HP DL380 G9 with 2 x 800GB SSD and 6 x 4TB Magnetic) however when creating the disk group only 2 disks were available for use.
After some investigation it turns out the other disks already had partitions, this was confirmed by running the following command:
Running the PartedUtil getptbl /vmfs/devices/disks/naa.5000xxxxxxxxx command fails with the error: “Error: Can’t have a partition outside the disk!”
To resolve this (and allow the disks to be added to a VSAN disk group) I ran the following:
partedUtil setptbl /vmfs/devices/disks/naa.5000xxxxxxxxxxx msdos
Then reboot the host.
***This will destroy any data already on the disks***