I recently needed to create a new Distributed Port Group and set a specific load balancing policy on an existing Distributed Switch. Nothing to exciting, but a task many have to complete. As this is a common repeatable task, i put together this short .ps1 to allow a repeatable way of completing this.
Just populate the Variables section with required information like so…
Save the file, then run the the .ps1 file from PowerShell prompt. (Ensure you have the PowerCLI Module installed; see my previous post)
Note you must add .\ to the beginning of the file name if you are executing the file from the directory you’re already in
Enter credentials with sufficient privilege in vCenter.
You will then see an output similar to this:
If you now take a look in the Web Client you will see the freshly created Distributed Port Group.
Creating just a single portgroup could potentially be quicker in the Web Client. What isn’t quicker, is multiple.
If you have a requirement to create multiple Distributed Port Groups on a vDS, you can use this script to do so in one go.
Just populate the Variables section with required information like above, then run the the .ps1 file from a PowerShell prompt. (Ensure you have the PowerCLI Module installed; see this post.
This uses and Array Table to build your source data, in this example, the PortGroup Name and VLAN ID for each. You can add further rows (more Port Groups) to the array by repeating the line in the red box, or add additional attributes by repeating the text from the green box on each line.
There are many ways you could modify this script to change the source of data, including ‘Get-Content’ from a .txt file for instance.
This year, as much as we have lost the ability to travel and connect with people in person at this event, it has presented an opportunity for individuals to attend from the comfort of the home or office that many have been unable to attend in person in previous year for a variety of reasons.
Don’t waste the opportunity! Head over to the website to register for this years VMWorld 2020! – https://www.vmworld.com/en/index.html. This years event is being held from 29th September to 1st October inclusive.
There are 2 pass options one of them is free! Why wouldn’t you attend?
The use of VMware tags recently became a requirement for some of my colleagues in an environment that was inherited. They were faced with being unable to create Tags & Tag Categories or Assign and Delete them, despite ‘having admin rights’.
Upon investigation it became apparent that while the admins had been granted the Administrators Role at the vCenter Object Level, they had had not been granted sufficient rights at the Global Permissions Level, or any rights for that matter.
The following graphic shows the vSphere Inventory hierarchy.
As you can see from the graphic, assigning privileges at the Global Level is required to manage Tags and additionally, Content Libraries.
You can see below a vSphere Admin, who has the Administrator Role assigned at the vCenter Level, is not able to select the New, Edit, Delete or Add Permission options for Tags or Tag Categories.
In this scenario there were two different permission requirements, one for a vSphere Admin team, the other for a Storage team both of which could be addressed by two existing roles; Administrators and Tagging Admin. You could of course create a custom role should you have a requirement to do so. Here are the privileges assigned to the tagging admin role for reference.
The vSphere Admin Team required the Administrator Role at the Global Level (root object) so they could manage Content Libraries and Tags, while the Storage Team required the ability to Create and Assign Tags only.
You can assign permissions to a user or a group from multiple Identity Sources, in this scenario, an Active Directory source. You will need to do this from an account that already has the Administrator Role at the Global Level. By default, the administrator@vsphere.local account has this privilege. (replace the domain as needed if you have used a different SSO domain name)
From the Menu, select ‘Administration’ and select the ‘Global Permissions’ option in on the left-hand side.
From here, select the Add Permission icon.
You can now select the domain of the user or group you wish to add from the drop-down list and begin to type the name of that user or group. It will begin to narrow your selection as you type.
Select the user.
Now select the appropriate role and select the ‘Propagate to child object’ option.
If you have multiple users, groups or roles you need to assign, repeat the process.
You will now see both permissions in the Global Permissions menu. If logged in, you will need to log out and back in for this to take effect. Both scenarios are shown.
If you now return to the Tags & Custom Attributes menu, logged in as a user from either of these groups, you will see that the New, Edit, Delete or Add Permission options for Tags or Tag Categories are now available.
Note: Providing a user or group privileges at the Global Permissions Level and selecting, ‘Propagate to child objects’ will give that user or group the privilege’s on the child objects such as vCenter, Cluster, VM and Datastore.
This can be useful if you have multiple vCenters in Enhanced Linked Mode (ELM) as you only need to apply it once.
vCenter –
Host –
Datastore –
Further information can be found in the following VMware article which explains how you can grant permissions on a Tag object, rather than at the Global or vCenter Levels to give you further granualar control.
I recently needed to validate some permissions using LDAP as an identity source. I hadn’t actually had a need to add an identity source to my Lab until now, so I set about adding my lab domain as a source, but hit the following error when trying to add it.
‘Check the network settings and make sure you have a network access to the identity source’
To start, I looked at connectivity, firewall rules, DNS forward and reverse lookup zones but still had the issue. It was none of these…
The issue? It was the format of the username… I originally used the format ‘domain\user‘. This doesn’t work. You need to use ‘user@domain‘ !
As soon as I changed the format, the source added successfully.
Some VMware links on setting up identity sources if you need some extra info –
I have been rebuilding my lab hosts a lot lately! Once because I fiddled too much with my vSAN cluster and killed it… Another more interesting occasion being the release of VCF 4.0 on VMUG and beginning the deployment of this!
I prefer to use Standard vSwitches for my management network in my labs and needed a quick and easy way to get the hosts back online with minimal effort. One thing I don’t like is seeing vSwitch0… I prefer seeing useful and descriptive naming, like I’m sure many others do!
Below are a few lines of PowerCLI to quickly and easily create a new vSwitch using a spare VMNIC (you should be using more than one physical NIC for resiliency), then migrate the Management VM Kernel adapter and original VMNIC over to it, followed by a clean up of vSwitch0.
#Variables<#ESX Host to target#> $ESXHost = "ESX102.lab.local"
<#Name of the Management Switch#> $ManagementSwitchName = "vSS_Management"
<#vmnic to be used for Management Switch#> $ManagementSwitchNIC = "vmnic1"
<#MTU size for Management Switch#> $ManagementSwitchMTU = "1500"
<#Name of the Portgroup for the VMKernel Adapter#> $ManagementVMKPortGroupName = "vSS_VMK_Management"
<#Name of the PortGroup for VM's#> $ManagementPGSwitchName = "vSS_PG_Management"<#Management VMKernal Nic to be migrated#>$vNic = "vmk0"
<#Management VMKernel assosiated pNic#>$PhysiscalNic = "vmnic0"
<#Old vSwitch#> $OldvSwitch = "vSwitch0"
#New Standard Management Switch
$NewSwitch1 = New-VirtualSwitch -VMHost $ESXHost -Name $ManagementSwitchName -Nic $ManagementSwitchNIC -mtu $ManagementSwitchMTU
$NewSwitch1 | New-VirtualPortGroup -Name $ManagementVMKPortGroupName -VLanId 0
$NewSwitch1 | New-VirtualPortGroup -Name $ManagementPGSwitchName
Once the new vSwitch is in place, the next block of code migrates the Management VM Kernel adapter and the VMNIC over to it.
Thanks for coming back! If you missed the first post in my Home Lab series you can find it here.
In this post I will begin drilling into the equipment and software that makes up my Home Lab and my reasoning for these choices.
I’m going to skip the original Raspberry Pi, there are enough blogs covering the use cases for them and begin at the first significant device; my MacBook Pro (late 2013). I wanted something mobile to start with so I could take it to work, use it on commutes to other offices etc. The MacBook came with an Intel i7 2.3Ghz Quad core chip, 16GB of memory and a 512GB SSD. This wasn’t going to be able to run everything, but its enough to run what I need when I’m away from home.
Before I dive into the VM’s and nested hosts, lets look at the networking configuration I used in VMware Fusion. I created four custom networks in total. One being a Management network for my ESXi Hosts and my VCSA. The second for vMotion and the other two as guest VM networks. None of these networks are NAT’d or have DHCP enabled, however I have selected the ‘Connect the host Mac to this network option in the VMware Fusion Preferences for the management network.
There are two ways to set these custom networks up. The first being the UBER Network Fuser and the second, editing the VMWare Fusion network file. In ‘/Library/Preferences/VMWare Fusion’, you will find the file called ‘networking’.
There are guides already available if you search google for either option so I won’t go into this further. This is the one I used – https://tinyurl.com/y7cjkhky.
Now onto the virtual machines. Running directly on VMware Fusion, I have a Windows Domain Controller / DNS Server, a PFSense firewall and two 6.7 ESXi hosts. They all use local storage, including the ESXi Datastores. My PFSense virtual firewall provides my layer 3 routing and eventually interfaces with my physical firewall. The Domain Controller/DNS Server is a ‘standard’ deployment, nothing special. The two ESXi hosts are the standard 6.7 image available from the VMUG Advantage subscription. Check out the last post for more on VMUG.
Then within ESXi, there’s my vCenter Appliance and the DR node of my vSphere Replication Appliances. At this point you might be wondering how I have fit this into 16GB of memory…
To start with, I built the first ESXi host with 12GB of memory and deployed my vCenter appliance on this (the tiny appliance requires 10GB). Once I had successfully deployed the appliance, I reduced the vCenter memory to 6GB and then followed this by reducing the ESXi host to 7GB.
I then created the second ESXi host, which also has has 7GB allocated. Its a tight squeeze but it allows me the basics I need when I’m not at home and there’s still enough room for some small VM’s with the nested ESXi hosts if needed.
One final thing… To ease the starting and suspension of this lab, I use the following script that I run from PowerShell on the Mac.
Having to downgrade a VM’s hardware version or compatibility level is something that comes up now and again. There are many reasons you may need to do this; being it moving a VM to an environment with an older version of vSphere, or having issues following a planned upgrade that you now no longer have a snapshot for.
Now this is only of use if you took a snapshot in the first place… If this is a planned upgrade, I would hope one was taken! However, you could have performed the upgrade and removed the snapshot before discovering the defect which is leading you to return to a lower hardware version.
If you do have an appropriate snapshot, reverting to it is a viable option. You can achieve this by the usual means. Right click the VM, hover over the Snapshot option and either select revert to snapshot, or manage snapshots if you have more than one or aren’t sure.
VMware vCenter Converter.
Another option is the VMware vCenter Converter. This is a free tool available from VMware that can perform a number of conversion tasks. One of these is the ability to copy the original VM to ‘another’ but allowing changes to the VM ‘hardware’ such as the hardware version, disk sizes, disk provisioning (Thick or Thin), CPU and memory changes and much more. (more info here —-). You also get the option to power off the original and power on the new as it completes. This method reduces downtime but can be heavy going with high IO machines , in fact I wouldn’t do it with high IO machines.
Once your conversion is complete, you can then delete original. This is a great option with a simple to follow wizard, however it can take a fair amount of time to complete depending on the size of the VM.
Original VM, Hardware Version 14.
During the conversion you will need to have either renamed the original VM inventory name, or use a temporary name during the conversion, which, you can return to the original name once you delete the original.
You have the option to select any hardware version
Now power off, rename back to the original name and perform a storage vMotion to rename the files on the datastore.
Detaching and Re-Attaching the disks.
This is my personal preferred method! If I only need to modify the VM hardware version, this is my go to. This involves creating a new VM with no hard disks and then attaching the disks from the original VM. This approach is particularly useful when your VM has large disks. Lets go through the process.
Create a New Virtual Machine giving it a temporary name, the required hardware version, and matching CPU, memory, SCSI controllers and network adapters. One additional setting you will need to take care with is that you match the Firmware option. Don’t worry about adding any hard disks. NB: If you have any dependencies for the original MAC addresses, if you take this route, you will need to note them and manually assign them to the new adapaters.
Now, ensure you have a backup, as you should do before any work, and take a snapshot the original VM to give you a fast rollback should you need it (quiesce the memory if you so wish). Power off the VM and rename it, <name>_old for instance.
Edit the VM settings and note the location of the disk(s).
Detach the hard disk(s), ensuring NOT to tick the option to delete from datastore (that will ruin your day…)
Now edit the new VM settings and attach an existing disk
Browse to the disk(s) location and attach the disks starting with the OS disk first.
Power on and you have now downgraded the hardware version. If you are using static IP addresses, be prepeared to reassign these.
So we now have a bit of cleaning up to do… The inventory name is incorrect and the disks aren’t stored with the VM.
You now need to power the VM off, rename it to the original name and perform a storage vMotion to rename and move all the VM files and disks into a single folder on the datastore.
When conducting any change, always ensure you have a backup and a valid rollback should something not go as planned!
Stephan McTighe 