In this post we will discuss about the different type of scsi controllers that are available with VMware vSphere and when to use which type of controller. We will discuss following topics in this post:

• What is SCSI controller and their types
• Why SCSI controller selection is so important
• Storage Controller Compatibility
• Adding/Changing SCSI controllers in virtual machines
• Changing controller type by modifying virtual machine vmx file

so lets get started.

What is SCSI controller and their types?

SCSI controllers are used by virtual machine to access SCSI disks and other SCSI devices such as CD/DVD ROM. SCSI controllers are added automatically when a VM is deployed. Controllers can be added/modified also post creation of VM.

When a VM is created, the default controller that is assigned to it is optimized for best performance and the controller selection depends purely on the guest OS chosen at the time of VM creation.… Read More

VUM Orchestrated upgrades allow you to upgrade the objects in your vSphere inventory in a two-step process: host upgrades followed by virtual machine upgrades. If you want the upgrade process to be fully automated, you can configure it on cluster level or you can configure this at the individual host or virtual machine level for granular control.

Before going ahead with orchestrated upgrade, we have to ensure that we have baseline groups created for hosts as well as VM’s. I will talk more on this later in the post.

In orchestrated upgrade, we have to first remediate the cluster against the host upgrade baseline (we covered creation/remediation in our last post). Once the hosts are upgraded, we remediate the same cluster against a virtual machine upgrade baseline group containing the VM Hardware Upgrade to Match Host and VMware Tools Upgrade to Match Host baselines.

How Orchestrated upgrade works?

• Orchestrated upgrade of ESXi Hosts

Patches/extensions and upgrades can be applied to an Esxi host by using host baseline group.… Read More

In last post we learn how to configure UMDS and how to enable VUM to use shared repository for downloading patches. If you are new to VUM/UMDS and by mistake landed directly on this page, I would encourage reading about them first from below links:

1: Installing vSphere Update Manager and Update Manager Download Service

2: Configure Update Manager Download Service

Also in past I have written one blog post on Creating Esxi hosts baselines and how to remediate host. You can read that post from here.

In this post I will be covering below objectives:

• Configure hosts/cluster settings
• Create VUM baseline group
• Manually download updates to a patch repository
• Import Host upgrade images and upgrade Esxi hosts.
• Configure Smart Rebooting for vApps

Lets get started.

1: Configure hosts/cluster settings

To configure hosts  maintenance mode settings, Login to Web Client and Click on  Update Manager icon from home page and naviate to Manage > Settings > Host and clusters settings >> Edit.… Read More

Last year I wrote a post on how to install and configure VUM and UMDS, but never got chance to connect UMDS to VUM and ended up downloading patches directly on VUM server via internet.

Once again I am playing with UMDS in lab and in this post we will cover why we need UMDS and how to configure it.

I am not covering steps for installing VUM/UMDS here because they are pretty straight forward and if you are new to these things, you can read the instructions about installation steps from here.

What is Update Manager Download Service?

Update Manager Download Service (UMDS) is an optional component which you can deploy with update manager. We can download upgrades for virtual appliances, patch metadata, patch binaries and notifications etc using UMDS.

Why we need UMDS when VUM is there?

Its a obvious question to ask that why we need UMDS when VUM is capable of downloading and installing patches on Esxi hosts/vApps.… Read More

Yesterday while reading about Enhanced linked mode I stumbled across this blogpost by William Lam where he have demonstrated how to split vCenters which are configured in linked mode.

I thought to give it a try in my lab also as these days I am playing around PSC’s and repointing, ELM things etc.

In my lab I have 2 PSC nodes and 2 vCenter server nodes each pointing to one of the PSC. Both PSC nodes are in same SSO domain/site

Both PSC are replicating to each other. Also I have verified that I do not have any stale entries for any PSC nodes from my existing lab activities.… Read More

Linked Mode was first introduced in vSphere 4.x and it has come a long way with vSphere 6.0.

Enhanced linked mode (ELM) allows administrators to manage multiple vCenter servers from one place using vSphere Web client. vCenter servers in ELM can replicate roles, permissions, licenses and policies between them.

ELM also enables Cross vCenter vMotion i.e you can migrate virtual machines across clusters on separate vCenter instances; subject to network limitations.

Previously linked mode configuration was only possible with Windows based VC as ADAM was used as the replication engine between the VC’s.

ELM in vSphere 6.0 don’t rely on ADAM anymore but have its own replication system which is a multi-master replication technology also called VMDir based on Open LDAP which means replication now works across Windows vCenter as well as vCenter appliances.

Note: All vCenters configured in ELM can be managed only from Web Client. If you are using vSphere C# client then you can only manage that vCenter server to which you are connected.… Read More

Prior to vSphere 6.0 U1 it was only possible to repoint vCenter Server which was deployed with external PSC to another PSC in same SSO domain. With vSphere 6.0U1, you can now reconfigure embedded vCenter server deployment to an external deployment.

Components of PSC which resides in embedded node are demoted and the repoints vCenter server to an external PSC node which resides in the same Single Sign On (SSO) domain as the source embedded node.

VMware made it possible by introducing an utility named cmsso-util and there are two main uses for cmsso-util:

Reconfigure

• Reconfigure is used when you want to point your vCenter server from embedded PSC to an externally deployed PSC.
• The source and target PSC should be in same SSO domain.

Repoint

• This is used when a vCenter is deployed with external PSC and you have one more external PSC and you want to move vCenter from source PSC to target PSC.

VMware introduced SSO with vSphere 5.1 and over the release SSO has matured very much. SSO can now be connected to multiple authentication domains, like active directory and ldap, so that it can exchange authentication for tokens which are used to access multiple vSphere services.

An Identity Source is a collection of user and group data, which is stored in either Active Directory, OpenLDAP or locally in the OS.

At the time of PSC/vCenter deployment we create one identity source (SSO domain) and after vCenter installation is completed, only the users defined under this SSO domain or localos can login to vCenter. This identity source is internal to vCenter SSO.

A SSO administrator can add additional identity sources for centralized authentication, can define the default identity source, and create users and groups in the default identity source.

In this post we will focus on below tasks:

• Define Identity sources for single sign-on.

In this post we will learn how to decommision/remove a PSC from SSO domain. I am covering steps needed for VCSA in this post. Steps for a Windows based vCenter server are very similar and is explained in VMware KB-2106736.

Why I need to do so?

In my lab I was doing a lot of new things with PSC deployments and repointing my vCenter server from one PSC to other. If you are new to how to repoint a vCenter server amongst PSC’s, please read below 2 articles:

1: How to repoint vCenter Server 6.x between External PSC within a site

2: Repointing vCenter Server 6.0 to External PSC’s across sites

At present I have 3 PSC’s namely psc02.alex.local,psc03.alex.local and psc03.alex.local. I have one vCenter server which was originally deployed with psc02 as external psc. First I moved my vCenter server from psc02 to psc03 (they were in same domain/site) and then I moved VC from psc03 to psc04 (they were in same domain but different site)

You can see in output of below command that which PSC is replicating to which other PSC