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.
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!
I was asked recently ‘Do we have PowerCLI downloaded?’. Yes, we may, but it could be anywhere and it is likely an outdated version.
There is no need to download the installer! You can install PowerCLI using the Install-Module cmdlet in Windows PowerShell. (Providing you have an internet connection!) Below we will look at the steps required to install the latest version of PowerCLI on your system.
From an elevated PowerShell prompt run the following –
If you don’t already have it installed, you will be prompted to install the NuGet Provider. Type ‘y’ and enter to continue.
You will get a further prompt to confirm you are happy to install a module from the ‘PSGallery’. Again, ‘y’ and enter to continue.
The PowerCLI Module will then begin to install. It will cycle through installing multiple dependent packages which will take a few minutes. Sit back and wait…
Once returned to the prompt, you can confirm the installation by running –
Get-Module VMware.PowerCLI -List Available | FL
You have now installed PowerCLI version 184.108.40.20647286. You will likely end up installing a later version.
Last step, load the module for use –
You’re ready to go! But…
Not every system you need to use this module on will have internet access. In this, case the ‘Save-Module’ cmdlet is your friend.
Save-Module -Name VMware.PowerCLI -Path <Path to directory>
The module will then proceed to be downloaded into the directory you have specified and will look like this –
On your target server, you will need to confirm your module paths. You can do this by using the following command. You may have more than one path.
Now copy the directory that contains the module you have saved, to a module path on the target server. Likely ‘C:\Programfiles\WindowsPowerShell\Modules’ on a Windows System.
Now the Module is on your system, all that’s left is to import the module as above –
Thanks for reading! Hope this has been of use and catch you in the next post.