Recently we were requested to install CA signed certificates on our ESX hosts to pass a security audit.
The thought of doing this manually bored me! so I wrote the following script – which recursively puts each host into maintenance, installs new certificate, then reboots the host, takes it out of maintenance and tests the certificate! The script also produces a detailed log file.
Continue readingWe recently realized the free space value on a single datastore in our VMware datastore cluster wasn’t matching the value of free space we were seeing on the backing device sitting on your VPLEX arrays. Not even close, as a matter of fact the underlying VLPEX distributed volume was fully utilized.
This clearly suggested something was going wrong with the deleted block unmap process.
To troubleshoot I jumped on a ESX host which has access to the particular datastore and run some esxcli cmds.
Continue readingIn AWS, under the EC2 instances view, you can customize the details you want to see about your EC2 instances, however once you do that there is no way of generating a CSV based EC2 instance report using the AWS UI. Plus you don’t have the option of displaying properties such as the VPC or Subnet name – which is a little annoying as working with long ids can get difficult. To make the reporting process a little easier, I put together the script below – which generates a CSV based report.
NOTE – The resulting CSV report is extremely detailed – you can simply remove properties you feel are unnecessary for your reporting purposes.
Before you can run this script install the AWS PowerShell Modules.
Install-Module -Name AWSPowerShell
Then I would recommend creating an access key profile in the SDK store – by running the following in PowerShell.
Set-AWSCredentials -AccessKey AccessKey -SecretKey SecretKey -StoreAs ProfileName
And to make things easier maybe associate a region with that profile.
Initialize-AWSDefaultConfiguration -ProfileName ProfileName -Region eu-central-1
Nothing revolutionary here, but I thought I’ll document the procedure as I happen to use it every now and then.
All VMs are assigned with a MoRef id when they are added to a vCenter deployment.
When you want to backup a VM using Veeam B&R, you add it into a pre-configured job using its name, however on the backend Veeam associates the VM with that job using the MoRef id.
If the VM which is being backed up by Veeam B&R is removed from the vCenter inventory (because you removed a whole host from vCenter or a VM was in an invalid state), the MoRef id for that VM will change when the VM is added back into the vCenter. Veeam will not register the MoRef id change automatically and kick off a new full backup (on the next backup cycle) for the same VM it previously backed up – thinking it’s a completely new VM (due to the unique new MoRef id).
To avoid a new full backup, you need to manually update the MoRef id for that VM in the Veeam database prior to the next backup cycle.
Note that the following steps are not supported by Veeam officially. Mess with the Veeam database at your own risk!
Continue readingIf you ever need to delete multiple volume snapshots from a NetApp HCI / Solidfire storage array, you will quickly realize there isn’t an efficient way of doing this using the UI – unfortunately you can’t delete multiple snapshots at the same time and each delete request requires a confirmation. Plus if you have a lot of volume snapshots, you will need to search for the snapshot you want to delete every time.
Using PowerShell simplifies the whole process.
First generate a snapshot report using following script.
connect-sfcluster CLUSTER IP
Get-SFSnapshot | select Name, SnapshotID, CreateTime, ExpirationTime, VolumeID, VolumeName | Export-Csv c:\temp\all-snapshots.csv
Sort the resulting CSV file (all-snapshots.csv) by VolumeName then by CreateTime – and highlight the rows including snapshots you want to delete. Then remove all the other rows. Finally remove all columns except the SnapshotID column and save as a new CSV (snapshots-to-delete.csv).
Now run the following script pointing at the new CSV file to delete the snapshots in one go.
$oldsnaps = (Import-Csv 'c:\temp\snapshots-to-delete.csv').SnapshotID
foreach ($snap in $oldsnaps){
Remove-SFSnapshot -SnapshotID $snap -Confirm:$False
}
For more info on how to install the SolidFire PowerShell module and other programmatic approaches to managing NetApp HCI storage – visit my other blog post.
This is a script which will allow you to enable the Hot Add vCPU and Memory feature on all or a sub set of your VMs.
IMPORTANT NOTE – the script will recursively power off each VM defined in CSV (unless Hot Add is already enabled), apply the config then power each VM back on. So make sure you run this script in an outage window.
When creating the CSV, make sure to include the header row – Name.
The script will also generate a log file.
Continue readingJust a few scripts I put together in preparation for a migration project which involves NetApp HCI iSCSI storage.
The same PowerShell modules work with Solidfire arrays as well.
Instructions on how to install the PowerShell modules and use them are in the following links.
https://blog.netapp.com/getting-started-with-powershell-for-netapp-hci/
Use the following script to create multiple volumes.
CSV should include a single column with header “Name” followed by volume names.
Volume name example:
BOOT-LUN-esx011
$Account = Get-SFAccount esxiboot
$QoSPolicy = Get-SFQoSPolicy -Name qos-policy-1
$Volumes = (Import-CSV C:\temp\volumes.csv).Name
foreach ($Volume in $Volumes)
{
New-SFVolume -Name $Volume -AccountID $Account.AccountID -TotalSize 7 -GB -
Enable512e:$true -QosPolicy $QoSPolicy.QoSPolicyID
}
I’ve got a new version of this script at this link.
This is a simple script which will allow you to enable the Hot Add vCPU and Memory feature on all or a sub set of your VMs.
IMPORTANT NOTE – the script will recursively power off each VM defined in CSV, apply the config then power each VM back on. So make sure you run this script in an outage window.
When creating the CSV, make sure to include the header row – Name.
#Function to generate wait time progress bar
function Start-Sleep($seconds) {
$doneDT = (Get-Date).AddSeconds($seconds)
while($doneDT -gt (Get-Date)) {
$secondsLeft = $doneDT.Subtract((Get-Date)).TotalSeconds
$percent = ($seconds - $secondsLeft) / $seconds * 100
Write-Progress -Activity "Sleeping" -Status "Sleeping..." -SecondsRemaining
$secondsLeft -PercentComplete $percent
[System.Threading.Thread]::Sleep(500)
}
Write-Progress -Activity "Sleeping" -Status "Sleeping..." -SecondsRemaining 0 -
Completed
}
#Variables
$HotAddVMs = Import-CSV c:\temp\hot_add_disabled_vms.csv
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.CpuHotAddEnabled = "True"
$vmConfigSpec.MemoryHotAddEnabled = "True"
Foreach ($VM in ($HotAddVMs)) {
#Shutdown Guest OS / Power off VM
Get-VM $VM.Name | Shutdown-VMGuest -Confirm:$false
#Wait for VM to power off before executing config cmd
section – in which case the config cmd will fail
while((Get-VM $VM.Name).PowerState -ne 'PoweredOff') {
Start-Sleep -Seconds 10
}
#Execute config cmd
$VMConfig = Get-View -VIObject $VM.Name
$VMConfig.ReconfigVM($vmConfigSpec)
#Power on VM
Get-VM $VM.Name | Start-VM
}
Last week I was looking for a way to bundle VM Hardware Upgrades with our monthly Guest OS patching. After the Guest OS is patched, it gets rebooted. The goal was to get the VMs to upgrade their hardware after the Guest OS is rebooted. And avoid having to power of the VMs to carry out the hardware upgrades.
It appears this is possible by changing the VM UpgradePolicy to “Always” and setting a VersionKey (i.e. the ESX compatibility level) using Powershell.
To prove that changing these VM settings I mentioned above actually triggers a Hardware Upgrade at Guest reboot, I built a test VM, then carried out the steps below.
I’ve simply used the scripts provided in this blog post. https://blogs.vmware.com/vsphere/2018/09/automating-upgrade-of-vmware-tools-and-vmware-compatibility.html
Continue readingThe other day I had to add 60+ new VMware datastores, rather than doing this manually using the vSphere web client wizard, I used a basic PowerCLI script (in a foreach loop) to create the datastores in one big bang!
Before carrying out these steps make sure new LUNs are presented to the ESXi host. And make a note of the LUN id of first new LUN you created.
NOTE – You can acquire the LUN id by analyzing “Runtime Name” of LUN. Or alternatively the storage array may have this information also.