vSphere 6.7 Released

VMware has just released vSphere 6.7 and everyone will be looking to see what the new features are and  possibly of upgrades. Here are some of the steps I usually follow:

• Check if the hardware that you wish to run vSphere 6.7 is supported, as per usual every release VMware will drop some support for some hardware support especially around CPU https://www.vmware.com/resources/compatibility/search.php. If your system is not listed then the next best bet for you is to visit your hardware vendors website to see if they have newer information. For example we have HPE servers and I obtain information from this page 
• Next step is to check all the other VMware products you have as part of your solution. You have to see if they are compatible with vSphere 6.7 and if there is an upgrade path for the version you are currently using https://www.vmware.com/resources/compatibility/sim/interop_matrix.php

Usually once I done the above then I know it is worth planning the upgrade path. Here is the main landing page for vSphere 6.7 https://blogs.vmware.com/vsphere/launch but I have also provided some of the direct links below to the articles in case they change them

• Introducing vSphere 6.7 

https://blogs.vmware.com/vsphere/2018/04/introducing-vmware-vsphere-6-7.html

• Introducing vCenter 6.7

https://blogs.vmware.com/vsphere/2018/04/introducing-vcenter-server-6-7.html

• Introducing faster lifecycle management operations in vSphere 6.7

https://blogs.vmware.com/vsphere/2018/04/introducing-faster-lifecycle-management-operations-in-vmware-vsphere-6-7.html 

• Introducing vSphere 6.7 Security

https://blogs.vmware.com/vsphere/2018/04/introducing-vsphere-6-7-security.html

• Introducing vSphere with Operations Management 6.7

https://blogs.vmware.com/vsphere/2018/04/introducing-vsphere-operations-management-6-7.html

• Introducing Developer Automation Interfaces vSphere 6.7

https://blogs.vmware.com/vsphere/2018/04/introducing-developer-automation-interfaces-vsphere-6-7.html

• Introducing vSphere 6.7 Enterprise Applications

https://blogs.vmware.com/vsphere/2018/04/introducing-vsphere-6-7-enterprise-applications.html


Documents on vSphere 6.7

• Read this KB before upgrades

https://kb.vmware.com/s/article/53704

• Release Notes for 6.7

https://docs.vmware.com/en/VMware-vSphere/6.7/rn/vsphere-esxi-vcenter-server-67-release-notes.html

• ESXi Upgrade

https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.esxi.upgrade.doc/GUID-65B5B313-3DBB-4490-82D2-A225446F4C99.html

• vCenter Upgrade Paths

https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vcenter.upgrade.doc/GUID-EB29D42E-7174-467C-AB40-DB37236FEAF5.html


I will be updating this page as I find more useful resources around vSphere 6.7

Azure Subscription Limits

During my time of doing a migrate of IaaS workload in to Azure I came across an issue where it reported that I had ran out of "core" resources. I was thinking how could I run out of resources? this is the cloud isn't it? is it not unlimited? After a quick case logged with Microsoft I was told we hit our "default limits" set by Microsoft.  You can raise these default limits by raising a case and as long as it is not an Azure limit you are hitting then they increase it free of charge for you. Every subscription for Azure has service limits, quotas, and constraints which are documented here on their website. To see your usage in your subscription you would select your "subscription", then "usage + quotas" and it will then display all your service quotas and how much you have used. You will see a button where you can request to increase the quotas.

This is good visually but ultimately we want to run a script where we can get the information so that  we can be manipulated it. For example we may want to run the script daily and then if the usage is above 75% then alert me then at least I can be more proactive. As you can see the above diagram has service limits for networks, IP addresses and NSG which at the moment I am not working on. As I am using Azure as a IaaS platform the information I am interested are related to CPU, storage accounts and number of VMs. There is a powershell command "Get-AzureRMVMUsage" which I will demostrate below on my script below. The script just goes through the subscription and every Azure location and returns the information about VM usages in each of the Azure location. The full script is available here at github. So here is the breakdown of my script

First we store some variables such as your Subscription name and the file name where we will store all the output of the information. The file will write to the current working directory that you are in. If there is a specific location you want to write the file to then please put in the full path and name of the file you want.

# Variables

$SubName = "Your Subscription Name"

# The file will be written in current directory that you have ran this script from

$FileName = "you file name.txt"

Next we login to your subscription and select the subscription you have defined above in the variable. We select the subscription in case your account has multiple subscriptions attached to it and we want to focus on a specific one

# Login to Azure Account

Login-AzureRmAccount

# Select Subscription to be used

Select-AzureRmSubscription -SubscriptionName $SubName

We run a command to store all the locations Azure has in a variable

# Get all available locations in Azure

$locations = Get-azureRmLocation

We are now at the heart of the script where we are looping through all the locations in Azure and running the command to gather all the VM usage in that particular location and write that information out to the text file

Foreach ($location in $Locations)

{

# Print to screen which location we are looping through

Write-Host $Location.Location

# Write the location to the file

$Location.Location | Out-File $FileName -Append

# Write the usage to the file

Get-AzureRMVMUsage -Location $location.Location | Out-File $FileName -Append

}

That's all in my script to get going. Once you run the script you will see something similar to what I have below showing just one of the Azure locations.

As you can see there are important information such as "current value" and "limits" against resources. So my example above you can see for "Total Regional vCPUs" for West Europe. I am currently using 6 and my limit is 20. As this information is retrieved via script it means that we can think of ways to apply some logic to only alert us when maybe a certain value is hit or a % value is met. Hope this script will get you started to expand and make it more powerful.

Decommissioning vCenter and PSC 6.0 f

We have just consolidated all our work load in two data centres down to one data centre and using the cloud as our DR site. So as we now have only one site it was time to decommission the PSC (Appliance version) and vCenter (Windows version) in the old data centre.

Here are the steps I followed to remove vCenter and PSC from my lab environment assuming you are running at least vSphere 6.0 Update 1 otherwise the command "cmsso-util" will not be available by default. I followed KB article 2106736 but added some steps I took.

• On the vCenter that you are going to decommission ensure that you have no more host managed by this vCenter. Check which PSC it is registered to by going to the web client. Select “vCenter > Manage > Settings > Advanced Settings” and look for “config.vpxd.sso.admin.uri”
• Now log on to the PSC where the vCenter is registered to via SSH or console as user “root”
• Run “shell.set --enabled True”
• Then run “shell”
• Run the command cmsso-util unregister --node-pnid vCenterServer_System_Name --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password. Replace "vCenterServer_System_Name" with your vCenter FQDN. For "administrator@your_domain_name" replace that with the vSphere domain SSO administrator details i.e. [email protected] and for "vCenter_Single_Sign_On_password" replace that with the password of the account you are going to use. Example "cmsso-util unregister --node-pnid vcenter6.myvmx.local --username [email protected] --passwd abcd123"
• Once you run this command you will receive a warning message “WARNING This step is irreversible! Are you sure you want to unregister host vcenter6.myvmx.local?”. At this point you can still type “N” to quit otherwise if you are happy then go ahead then type “y”
• It will run a command to unregister your vCenter with the PSC and this could a bit of time and you should get response messages of “success”
• Once that command has completed and has been successful then you can power off vCenter as it is not part of the solution anymore. You can now delete the decommission the VM with your usual process
• If you log into your vCenter. Go to "Administration > System Configuration > Nodes" you should see that the vCenter is not registered at all.

Our next step is to decommission our PSC as well from our environment. 

• Log on to a PSC that you WILL NOT be decommissioning and has a replication relationship with the PSC that you are decommissioning. If you are not sure if it has a relationship then we can do the following 
• Log on to the PSC via SSH or console
• Run “shell.set --enabled True”
• Run “shell”
• Run “cd /usr/lib/vmware-vmdir/bin” which will take us to the directory where the replication admin command is
• Run the command  "./vdcrepadmin -f showpartners -h Source_hostname -u Source_username -w Source_password" . Replace "source_hostname" as the PSC you are currently on, use the vSphere "Administrator" account as the "source_username" and use the password for this account. Example would be ./vdcrepadmin -f showpartners -h psc1.myvmx.local -u administrator -w abcd1234 
• This will show the partners that is connected to the PSC that you are currently on
• You can then run this command "./vdcrepadmin -f showpartnerstatus -h Source_hostname -u Source_username -w Source_password which will tell you the status of the partners with this PSC
• Once you are satisfied that this PSC is a partner with the PSC you wish to decommission then we run same "cmsso-util" command on this PSC "cmsso-util unregister --node-pnid Platform_Services_Controller_System_Name --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password". Replace "Platform_Services-Controller-System_Name" with your FQDN of the PSC that you wish to decommission. "Change administrator@your_domain_name" with your vSphere SSO domain name. Example "cmsso-util unregister --node-pnid psc6.myvmx.local --username [email protected] --passwd abcd123"
• Again you will receive a message that  "This step is irreversible!" and if you are happy to continue then press “y” otherwise “n”. Once this command is successful then you will see that the node of this goes from vCenter as well in "Administration > System Configuration > Nodes"

I did hit across one issue when I performed the above in my production environment. When I logged in to the web client. I was still receiving this message "Could not connect to one or more vCenter Server systems: https://vCenter_Server_Name:443/sdk"

I SSH back to my working PSC and ran the command "./vdcrepadmin -f showpartners -h Source_hostname -u Source_username -w Source_password"  (replace informatiion where needed) which showed that I still had a relationship with the old PSC. I found a command called "vdcleavefed" where you can use it to remove an offline server.

So as an example I used "./vdcleavefed -h vcenter6.myvmx.local -u administrator -w abcd1234". You will see it goes through the process to remove from the "federation" and once completed you may need to wait for a while for the replication to complete. After that I logged back in to vCenter and the message went away.