vSphere 6.0

Deployment models for vSphere Content Library

12/01/2017 by William Lam 2 Comments

When talking to customers about vSphere Content Library deployments, one question I normally get is how best deploy Content Library for optimal workload deployment, especially in scenarios where remote or branch offices are involved? There are two main deployment models for vSphere Content Library as the title has alluded to. The main difference between the two is whether you have a single vCenter Server or if you have multiple vCenter Servers, with each managing its own vSphere infrastructure?

Lets refer to the single vCenter Server case as Scenario 1 and the multi-vCenter Server case as Scenario 2 and below are the two scenarios outlined with additional details.

Scenario 1 (Single vCenter Server):

In this scenario, which is a fairly common deployment for many smaller to mid-size organizations, where you only have a single or very few vCenter Server(s). They are used to manage several remote locations which only consists of ESXi hosts running at each of the locations and storage local to the site is available. In addition, there are several expected behaviors of the content itself which I have formulated into the following table below:

Content Management	Content Distribution	Content Deployment
Centrally Managed	Sync across the WAN	Workloads stored and deployed locally

For this type of an environment, you would first setup a published library which stores all the content that you wish to distribute across your remote sites. Next, you would create subscriber library(s) consuming the published library, but instead of storing the replicated content locally, it is actually stored at each of the remote locations and their respective vSphere Datastore(s). This ensures that content is synchronized from our published library out to each of the remote locations, but when content is requested for deployment, the traffic is local to the site rather than going across the WAN.

In the above scenario, since there is only a single vCenter Server, if it ever becomes unavailable then provisioning and management to the remote location will also be unavailable. This is the expected behavior regardless if Content Library is configured.

When to use Move-VM cmdlet vs xMove.ps1 script for performing Cross vCenter vMotions?

10/26/2017 by William Lam 10 Comments

Since publishing my Automating Cross vCenter vMotion between the same and different SSO Domain article back in early 2016, I have had a large number of customers reach out to me and share their success stories of allowing them to perform datacenter migrations to consolidating vCenter Servers all due to this awesome capability that was introduced in vSphere 6.0. In fact, many of the VM migration numbers were in the 4,000 to 8,000+ range which completely blew me away. It was great to hear from customers on how the xMoveVM.ps1 script had enabled them to do things that was simply not possible before, especially without impacting their workloads.

I still get pinged on a regular basis from customers about using my script and one thing that surprises many customers when I mention to them that this functionality has already been ported over to the native Move-VM cmdlet that was introduced with the PowerCLI 6.5 release. This had always been my original intention to provide an example using our vSphere API and enabling our customers in the short term and working with Alan Renouf and the PowerCLI team to get this folded back into the official PowerCLI cmdlets. This means, you no longer have to use my script for basic Cross vCenter vMotions whether that is between the same or different SSO Domain, which is quite nice as the number of user inputs is significantly reduced by using Move-VM cmdlet.

UPDATE (01/01/2018) - One additional option is the recently released Cross vCenter vMotion Utility Fling. For more details, please have a look at the blog post here.

Lets take a look at an example below where I have a VM called TestVM-1 which is residing in vcenter65-1 and I want to vMotion it to vcenter65-3:

With just 5 simple and easy to read lines of PowerCLI, you can perform this operation:

Maximum number of vCenter Servers per Single Sign-On (SSO) Domain

03/29/2017 by William Lam 9 Comments

This particular question and its variations have been raised quite a bit lately by our field and customers. For me, this was an opportunity to see if we can provide some additional clarification and help explain some of the nuances that may have been causing some of the confusion around the supported maximums for both vCenter Server and the Platform Services Controller (PSC).

In the vSphere 6.5 Configuration Maximum, there are three specific maximums that helps us answer our question on the maximum number of vCenter Servers per vCenter Single Sign-On (SSO) Domain. I will go through each of the maximums and provide some additional context that will help us derive the answer to our question.

The first is the "Linked vCenter Servers" which defines the maximum number of vCenter Servers that can be supported in an Enhanced Linked Mode (ELM) configuration. What is interesting about this particular maximum is that it actually answers the majority of our question. By definition, an ELM consists of a single SSO Domain. This then means that you can only have a maximum of 10 vCenter Servers per SSO Domain.

vCenter Server Maximum

Configuration	Maximum
Linked vCenter Servers	10

The second is the "Maximum PSCs per vSphere Domain" which defines the maximum number of PSC's that can be part of a single SSO Domain, pretty straight forward. The third is the "Maximum PSCs per site behind a load balancer" which just adds an additional constraint when using a load balancer with your PSCs.

Platform Services Controller Maximum

Configuration	Maximum
Maximum PSCs per vSphere Domain	10
Maximum PSCs per site behind a load balancer	4

Cross vCenter Server operations (clone / migrate) between versions of vSphere 6.x

02/27/2017 by William Lam 7 Comments

When cross vCenter Server operations such as clone and migrate was first introduced in vSphere 6.0, it required that both the source and destination vCenter Server (includes ESXi hosts) to be running the same vSphere version. With the release of vSphere 6.5, this base requirement still holds true (e.g. vSphere 6.5 for both source and destination), especially when performing these operations using the vSphere Web Client where mixed-vSphere versions is not supported outside of a rolling upgrade.

Having said that, it is possible and supported to clone or migrate a VM across different versions of vSphere 6.x, for example a vSphere 6.5 and a vSphere 6.0 Update 3 environment. This can be accomplished by performing a xVC-vMotion or xVC-Clone operation using the vSphere API. For the the xVC-vMotion use case, I have extensively written about it here and here and with PowerCLI 6.5r1, the Move-VM cmdlet has even been updated based on my feedback to support this capability natively. Furthermore, you can even perform these operations across completely different vCenter Single Sign-On Domains, which enables a new level of mobility for your VMs and access to resources of independently deployed vCenter Server instances.

UPDATE (11/01/17) - The following VMware KB 2106952 has just been updated to reflect what is officially supported in terms of Cross vCenter Operations ( Clone / Migrate) across different versions of vSphere. The matrix in the KB reflects what has been tested by Engineering and one thing you may notice is that Cross vCenter vMotion/Clone from vSphere 6.x to vSphere 6.5 is only supported when running at least vSphere 6.0 Update 3. After speaking with the PM, the reason for this change is that pre-vSphere 6.0 Update 3, there were no pre-checks in the code to prevent Cross vCenter Operations for un-supported target hosts such as ESXi 5.5, which could lead to poor user experience as well as undefined failure scenarios. In addition, vSphere 6.0 Update 3 also includes additional enhancements to properly clean up failed provisioning operations which will make Cross vCenter Operations much more robust. Due to these reasons, though it is possible to perform Cross vCenter vMotion from earlier versions, it will not be officially supported. I have also updated my summarized table below to reflect what is in the VMware KB, but please use the KB as your official source of truth for what VMware supports.

To help make sense of the different combinations of vMotions and cloning operations, below are a few tables to help outline what is possible and supported today.

vMotion

Source vCenter Server	Destination vCenter Server	Supported	UI or API
vSphere 6.0	vSphere 6.0	Yes	UI and API
vSphere 6.x (pre 6.0 Update 3)	vSphere 6.5	Possible but Not Supported	N/A
vSphere 6.0 Update 3	vSphere 6.5	Yes	API
vSphere 6.5	vSphere 6.5+	Yes	UI and API
vSphere 6.5	vSphere 6.x	No	No
vSphere 6.5+	VMware Cloud on AWS	Yes	UI and API
VMware Cloud on AWS	vSphere 6.5+	Yes	UI and API

Cold Migrate

Source vCenter Server	Destination vCenter Server	Supported	UI or API
vSphere 6.0	vSphere 6.0	Yes	UI and API
vSphere 6.x (pre 6.0 Update 3)	vSphere 6.5	Possible but Not Supported	API
vSphere 6.0 Update 3	vSphere 6.5	Yes	API
vSphere 6.5	vSphere 6.5	Yes	UI and API
vSphere 6.5	vSphere 6.x	No	No
vSphere 6.5+	VMware Cloud on AWS	Yes	UI and API
VMware Cloud on AWS	vSphere 6.5+	Yes	UI and API

Clone

Source vCenter Server	Destination vCenter Server	Supported	UI or API
vSphere 6.0	vSphere 6.0	Yes	UI and API
vSphere 6.x (pre 6.0 Update 3)	vSphere 6.5	No	N/A
vSphere 6.0 Update 3	vSphere 6.5	No	N/A
vSphere 6.5	vSphere 6.5+	Yes	UI and API
vSphere 6.5	vSphere 6.x	No	N/A
vSphere 6.5+	VMware Cloud on AWS	Yes	UI and API
VMware Cloud on AWS	vSphere 6.5+	Yes	UI and API

Virtual Networking Migration

Source Type	Destination Type	Supported
VDS	VDS	Yes
VDS	VSS	No
VSS	VSS	Yes
VSS	VDS	Yes

Note1: vMotioning and/or cloning of VMs which uses the new vSphere Encryption feature introduced in vSphere 6.5 is not supported.

Note2: "Compute" only xVC-vMotion insufficient space issue has now been resolved with vSphere 6.0 Update 3, see this post here for more details.

Note3: xVC-vMotion is not supported on 3rd party switches as we can not checkpoint the switching state.

Here are some additional xVC-vMotion and vMotion articles that may also useful to be aware of:

Will I get Photon OS when I upgrade my VCSA 5.5/6.0 to VCSA 6.5?

11/04/2016 by William Lam 7 Comments

There seems to be a bit of confusion on how the upgrade from an existing vCenter Server Appliance (VCSA) 5.5/6.0 to the upcoming VCSA 6.5 release will work. I suspect part of the confusion is also due to the fact that the underlying OS in the VCSA in vSphere 6.5 is changing from SLES to VMware's very own Photon OS. Before going into the upgrade details, I do want to mention that with this change, VMware will now own the entire software stack within the VCSA (OS + Application). This will allow VMware to quickly respond and deliver OS and security updates to customers at a much quicker rate than it was possible before. In addition, Photon OS is also a very optimized Linux distribution which has allowed VMware to significantly improve the reboot and startup time of the vCenter Server application. To be clear, the vCenter Server application itself is NOT running as a Docker Container nor are there any other application or services within the VCSA that is running a Docker Container, I know this was something folks were also assuming because the OS changed to Photon OS.

Now going back to the upgrade question, how would an upgrade work if the underlying OS is changing? The answer is actually quite simple. VCSA upgrades are "Migration" based upgrades and has been since the very first release of the VCSA in vSphere 5.0.

So how does it work? Here is the high level workflow:

The new VCSA 6.5 is deployed using the standard VCSA UI or CLI installer using the "Upgrade" option. It does require a temporarily IP Address (DHCP or Static)
The VCSA 6.5 then connects to the existing VCSA 5.5/6.0 and starts copying (migrate) the data from the old VCS to the new VCSA
The existing VCSA 5.5/6.0 is then shutdown, the new VCSA 6.5 now takes over the personality of the original VCSA and you have now successfully upgraded

As you can see from this workflow, your existing VCSA is not actually being upgraded but rather its data is migrated over to the new VCSA. Once the upgrade has completed, you will now be on the new Photon OS based VCSA. Hopefully this clears up any confusion 🙂

Lastly, I should also mention that in vSphere 6.5, we have an updated version of the VCSA Migration Tool simliar to the one release with vSphere 6.0 Update 2m. It will now support migrating from a Windows-based vCenter Server running either vSphere 5.5 or vSphere 6.0 to VCSA 6.5.

How to check the size of your Config & SEAT data in the VCDB in vPostgres?

10/20/2016 by William Lam 1 Comment

After publishing my article on how to check the size of your vCenter Server's Configuration and Stats, Events, Alarm & Tasks (SEAT) data for both a Microsoft SQL Server and Oracle based database, I had received a few requests for doing the same for the vPostgres database which the vCenter Server Appliance (VCSA) uses exclusively. Thanks to one of our Engineers who works on the VCDB, I was able to quickly get the relevant SQL query to perform the exact same lookup as the other two databases.

Since the VCSA is harden and locked down by default, being able to remotely retrieve this information will actually require some additional configuration changes to your VCSA which may or may not be acceptable. Because of this constraint, I will provide two options in how you can perform this SQL query.

The first option (easy) will be running the SQL query directly from within the VCSA. You just need SSH access and no other information or credentials will be required. The second option (complex) will be to remotely connect to the vPostgres database (generally not recommend) which will require the VCDB's credentials which I will show you how to retrieve. Lastly, I want to quickly mention that in the upcoming vSphere 6.5 release, this information will be super easy to view not only from a UI but also API as shown in tweet below.

Want to see breakdown of your vCenter Server Database in the VCSA? You can now using either UI or API within VAMI interface!#vSphere65 pic.twitter.com/htOzb93aei

— William Lam (@lamw) October 18, 2016

Option 1:

Step 1 - Download the following shell script called queryVCDBvPostgres.sh which contains the respective VCDB SQL query.

Step 2 - SCP the shell script to your VCSA and then login via SSH.

Step 3 - Run the following command to make the script executable:

chmod +x queryVCDBvPostgres.sh

Step 4 - Run the script by issuing the following command:

./queryVCDBvPostgres.sh

Here is a screenshot of what you should see which is a break down of your Config + SEAT data:

Option 2:

Step 1 - Login to the VCSA using SSH.

Step 2 - Edit /storage/db/vpostgres/postgresql.conf and add the following entry:

listen_addresses = '*'

This will allow vPostgres to be connected to from any address or if you want to restrict it to a specific IP, you can also just specify that.

Step 3 - Edit /storage/db/vpostgres/pg_hba.conf and add the following entry:

host all all 172.30.0.0/24 md5

Similiar to the previous configuration, you can either specify a network range using CIDR notation or a specific IP Address.

Step 4 - Edit /etc/vmware/appliance/firewall/vmware-vpostgres and replace it with the following entry:

{
  "firewall": {
     "enable": true,
        "rules": [
        {
          "direction": "inbound",
          "name": "vpostgres_external",
          "port": "5432",
          "portoffset": 0,
          "porttype": "dst",
          "protocol": "tcp"
        }
     ]
  },
  "internal-ports": {
    "rules": [
      {
        "name": "server_port",
        "port": 5432
      }
    ]
  }
}

{

"firewall": {

"enable": true,

"rules": [

{

"direction": "inbound",

"name": "vpostgres_external",

"port": "5432",

"portoffset": 0,

"porttype": "dst",

"protocol": "tcp"

}

]

"internal-ports": {

"rules": [

{

"name": "server_port",

"port": 5432

}

]

}

This will open up the VCSA's firewall to allow remote connections to the vPostgres port which the default is 5432.

Step 5 - Next, we need to reload the firewall configuration by running the following command:

/usr/lib/applmgmt/networking/bin/firewall-reload

Step 6 - We can verify by running the following command:

iptables -L | grep postgres

Here is a screenshot of what you should see as the output:

Step 7 - Lastly, we need to restart the vPostgres service by running the following command:

service vmware-vpostgres restart

Step 8 - To verify that you can now remotely connect to the vPostgres DB, run the following command:

netstat -anp | grep LISTEN | grep tcp | grep 5432

Here is a screenshot of what you should see as the output:

At this point, you have now enabled remote connections to the VCSA's vPostgres DB. The next step is to retrieve the VCDB credentials which you will do so using a PowerShell script that I have written to perform the remote SQL query. This will also require that you setup an ODBC connection on your client system to communicate with the vPostgres DB. Please have a look here for more information on how to setup the ODBC connection.

Step 9 - Login to VCSA via SSH and then look at the /etc/vmware-vpx/vcdb.properties and you should see the password to your VCDB. Go ahead and record this some where as you will need it in the next step. The username for the DB will be vc which you can also make a note of.

Step 10 - Download the following PowerShell script called Get-VCDBUsagevPostgres.ps1 and provide the connection details that you retrieved in Step 9. If everything was properly configured, you can run the PowerShell script and it should produce a similiar output as shown in the screenshot below.