Author: lifeofbrianoc

My name is Brian O’Connell. I work for VMware as part of the Integrated Systems Business Unit (ISBU) working on VMware Validate Designs (VVD) & VMware Cloud Foundation (vCF). I am an IT geek at heart and love playing with new technologies. I started my career in an IT services role as a Systems administrator for SMB’s and moved to EMC in 2010 where I worked for the EMC vLab team developing content for the ever expanding vLab cloud platform. I moved into working with the EMC Cloud Engineering Team primarily focused on the EMC Enterprise Hybrid Cloud Solution (EHC). I am also a husband to a beautiful wife, father to 2 beautiful daughters and a musician (or failed rock star depending on how you look at it!)

VMware Validated Design – Automated Deployment with Cloud Builder – Part 4: Generating SSL Certificates

~ lifeofbrianoc ~ 1 Comment

This is part 4 of a series of posts on VMware Cloud Builder.

In this post I will cover generating the required SSL certificates for deploying this VMware Validated Design with VMware Cloud Builder.

Friendly warning: This is a long post so maybe get a coffee before reading!

Continue reading “VMware Validated Design – Automated Deployment with Cloud Builder – Part 4: Generating SSL Certificates” →

VMware Validated Design – Automated Deployment with Cloud Builder – Part 3: Deployment Parameters File

~ lifeofbrianoc ~ Leave a comment

This is part 3 of a series of posts on VMware Cloud Builder.

In this post I will cover the deployment parameters file.

Continue reading “VMware Validated Design – Automated Deployment with Cloud Builder – Part 3: Deployment Parameters File” →

VMware Validated Design – Automated Deployment with Cloud Builder – Part 2: Environment Prerequisites

~ lifeofbrianoc ~ 5 Comments

This is part 2 of a series of posts on VMware Cloud Builder.

In this post I will cover the initial environment prerequisites required before you can deploy your VMware Validated Design SDDC with Cloud Builder. These fall into 5 key areas:

  1. Prerequisites for Virtual Infrastructure Layer Implementation in Region A
  2. Prerequisites for Operations Management Layer Implementation in Region A
  3. Prerequisites for Cloud Management Layer Implementation in Region A
  4. Prerequisites for Business Continuity Layer Implementation in Region A
  5. Generate Certificates for the SDDC Components in Region A

Continue reading “VMware Validated Design – Automated Deployment with Cloud Builder – Part 2: Environment Prerequisites” →

VMware Validated Design – Automated Deployment with Cloud Builder – Part 1: Overview

~ lifeofbrianoc ~ 3 Comments

This is the first in a series of posts on VMware Cloud Builder – The automated deployment engine for VMware Validated Design – which delivers consistent and repeatable Software-Defined Datacenter (SDDC) deployments across your regions. Hopefully you will find it useful!

Continue reading “VMware Validated Design – Automated Deployment with Cloud Builder – Part 1: Overview” →

VMware Validated Designs 5.0 – What’s New?

~ lifeofbrianoc ~ Leave a comment

VMware Validated Designs is a complete set of prescriptive blueprints on how to deploy a VMware based Software-Defined Datacenter (SDDC). It includes Planning & Preparation guidance, detailed Architecture & Design documentation, design decisions – including justifications & implications for each decision – deployment guidance, upgrade guidance and now automated deployment. All of which is created by a team of VMware architects working behind the scenes with every VMware business unit…all with a view to ensuring that deploying the VMware SDDC is consistent & effortless for customers and partners.

Today saw the release of VMware Validated Designs 5.0. The documentation can be found here. I will delve into some of this in more depth in future posts but here are the highlights of today’s release

EDIT: I missed a major addition in the VMware Validated Designs 5.0 release – The new Document Map. This map provides guidance on how and when to navigate each document to make the documentation flow easier to consume

Continue reading “VMware Validated Designs 5.0 – What’s New?” →

Beware VLAN double tagging!

~ lifeofbrianoc ~ Leave a comment

In setting up some additional ESXi hosts in an aforementioned lab we ran into an issue where we could not communicate with the new hosts after setting static IPs and relevant management VLANs on them. The hosts are connected to 2 TOR switches (Cisco 9K Top Of Rack). Investigating on the switch you could see the hosts connected on the expected port on each switch (Ethernet 1/14 on each) by searching the mac address table for the relevant mac

Continue reading “Beware VLAN double tagging!” →

NSX IPSec VPN between datacenters (multi site/region)

~ lifeofbrianoc ~ 1 Comment

I’m doing some lab work with my team at the moment and we were gifted some hardware to do some multi region validation. Both systems (a VxRack SDDC & a VxRail) are in 2 separate datacenters, and both are using private IP addressing that is not routable between datacenters. As part of the validation we need both systems to be able to communicate with each other, however we dont control the inter lab switching to put in place the necessary routes to enable this. Rather than go through a change control process with the keepers of that gate we decided to get creative and have some fun (and hopefully learn something!) by setting up an NSX IPSec VPN between the labs.

Disclaimer: There are many better ways to do this for a permanent lab setup (i.e. BGP to the core with routes) but this was done on borrowed kit that was never initially designed with inter lab routing as a requirement, with no direct control on the inter lab switches, and we would also like to put it back the way we found it so dont want to make sweeping architectural changes!

Continue reading “NSX IPSec VPN between datacenters (multi site/region)” →

Managing VMs via the ESXi command line

~ lifeofbrianoc ~ 1 Comment

From time to time a host may be unmanageable from vCenter / web client or you may only have console access. In my case I was bringing up a Dell EMC VxRail. During initial bringup the ESXi hosts do not get a mgmt IP if you do not have DHCP available so management with the web client is not possible. I do have iDRAC access though so can access the console. I needed to see where the VxRail manager VM was running as it comes up during an election process between the hosts. With console access it is still possible to manage VMs using esxcli.

To discover all VMs on a host run the following

  • vim-cmd vmsvc/getallvms

Once you have the output you can use the Vmid to manipulate the powerstate of a VM

  • vim-cmd vmsvc/power.get 2

In my case the VM i wanted was powered off. You can run the following to power it on

  • vim-cmd vmsvc/power.on 2

 

And there you have it. Simple VM management using vim-cmd. Explore what else you can leverage it for here

Quick Fix: The trust relationship between this workstation and the primary domain failed…

~ lifeofbrianoc ~ Leave a comment

We’ve all been there…attempt to open an RDP session to a VM you haven’t connected to in a while and you see the message above! Traditionally the fix for this was to log on as a local admin user, remove the VM from the AD domain (add to workgroup), reboot, log in again, add to AD domain, reboot….well here is a quicker way of resolving the issue with PowerShell.

Modify the username, password and domain controller FQDN and save the following as ResetDomainMembership.ps1 and run on the affected VM as a local administrator


$password = "Password123!" | ConvertTo-SecureString -asPlainText -Force
$username = "domain\administrator"
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Reset-ComputerMachinePassword -Server dc01.domain.local -credential $credential
shutdown -r -t 0

Tip: If you dont want to include the password in the script as this is a security concern you can use a Read-Host command to prompt the user for the password


$password = Read-Host -asSecureString "Please enter the password"

Cleanup failed requests in vRA UI

~ lifeofbrianoc ~ Leave a comment

From time to time a request in vRA will fail for whatever reason. When this happens you will see the request status as failed on the requests tab. There is a greyed out delete button that for whatever reason cannot be used to delete the failed request even when logged in as a full tenant/iaas/cloud admin.

 

There are several reasons you may want to remove failed requests…maybe you may need to deliver a demo to the CIO on some new functionality and failures in the UI never look good…or maybe you just have mild OCD like me and like to cleanup any failures to restore the illusion of all being good with the world! 🙂 Whatever your reasons here is a procedure that you can use.

Disclaimer: I dont believe this procedure if fully supported by VMware so please proceed with caution.

  • SSH to your primary vRA appliance
  • Run the following to view the contents of /etc/vcac/server.xml
    • less /etc/vcac/server.xml
  • Look for the line with password= and copy everything between the “”. This password will allow you to connect to the vRA PostGres DB

  • Run the following command with the password from the above step
    • vcac-config prop-util -d –p “s2enc~K6RsAv5WGpoAt+qsnZPrKErxZ0kU1npeK/G5iMzyaWI=”
  • Next change to the postgres user
    • su postgres
  • Change to the postgres directory
    • cd /opt/vmware/vpostgres/current/bin
  • Connect to the vcac database
    • ./psql vcac -W
  • Enter the password from server.xml
  • vRA requests are store in the cat_request table. To enable us to delete a request we first need the request id. Query the cat_request table for your request ID using the requestnumber (In my case the offending failed requestnumber is 63, as seen in the first column in the screenshot above. replace with your requestnumber)
    • SELECT id,requestnumber FROM cat_request where requestnumber = ’63’;

vRA XaaS blueprint requests are referenced in 1 further table, cat_requestevent. This entriy must be deleted before you can delete the request.

  • Run the following commands to delete the request.
  • delete from cat_requestevent where request_id =’4dc74fc2-f855-4eb1-94d6-65481b702acd’;
  • delete from cat_request where id =’4dc74fc2-f855-4eb1-94d6-65481b702acd’;

The offending failed request should now be gone from the requests list in vRA!