powercli

Host prep scripts for deploying & redeploying VCF

Hello! Long time, no scripting! I’ve been blowing through VCF, deploying, redeploying, and built some scripts to help me with this. Sharing is caring, read on to see what I’ve done…

PowerCLI script to migrate clusters to new vCenter

Hey scripters! I recently had a task of migrating an entire virtual datacenter from one vCenter to another. It sounds like a pretty simple task, but manually recreating the cluster(s) could cause some human errors. I decided to write a script that would look at a specific vDatacenter and get all it’s clusters, then recreate that tree in the new vCenter. It’s pretty simple, really, it pulls all the clusters, then creates new clusters with the same attributes. When moving over the hosts, it first disconnects them from the original vCenter, then removes them from inventory.

I thought about disabling HA & DRS on the source vCenter cluster right before hand, but manually disconnecting & removing shouldn’t be an issue. If you add the host to the new vCenter without first removing from the old vCenter, that’s when you’ll get some HA weirdness because the old vCenter doesn’t know what just happened.

What does it do?

Reader Request: Scripted VM Conversion to Thick from input CSV file using PowerShell PowerCLI

A few days ago I received a comment on This Post requesting a custom script to take a list of VMs from a file and convert them to thick. I quickly slapped something together and sent it to him for testing.

**REMEMBER** When converting thin to thick (or vice versa), you have to actually migrate the VM to a different datastore.

I’m posting this because it can be coupled with another post I have about Exporting VMs with Thin Disks to a CSV file, which would work perfectly for this. Run this one first to get a CSV with all your thin provisioned VMs.

In the Export Thin script, you will need to change the VM header in the CSV file to Name, since that’s what the migrate script looks for (or change the migrate script, up to you), add in a Destination header for the destination datastore in the CSV file after it’s exported. You could then plan it all out so your VMs are moved to specific datastores.

Added VMware’s PowerCLI cmdlets to the powershell.php for WP-Syntax & GeSHi

I added a bunch of cmdlets for VMware’s PowerCLI to the cmdlets array in the powershell.php file.

So you don’t have to export and copy & paste them in to yours, I attached it to this post.

This is for the WP-Syntax plugin for WordPress that uses GeSHi to highlight certain things in the pre tag.

powershell.php

Just thought I’d share…

PowerCLI one liner to move all VMs on one datastore to another and convert to thick or thin

I wrote this post a while back on how to use the API to convert VMs from thin to thick, which you could also go from thick to thin using it. I had written it because I was trying to use the inflate function, which isn’t allow against powered on VMs.

It was pointed out by a reader that I could have simply used Move-VM to accomplish the same task. This is great, shows how a second set of eyes and a different perspective can help you solve the problem. You could simply do

Move-VM vmservername -Datastore datastorename -DiskStorageFormat thick

1	Move-VM vmservername -Datastore datastorename -DiskStorageFormat thick

and it will move your VM to the specified datastore and convert to thick. You could use either thin or thick.

If you wanted to move every VM on a datastore, say Datastore1, to a new datastore, say Datastore2, and convert all of them to either thin or thick, you could do it like this:

Get-VM -Datastore Datastore1 | Move-VM -Datastore Datastore2 -DiskStorageFormat thick

1	Get-VM -Datastore Datastore1 \| Move-VM -Datastore Datastore2 -DiskStorageFormat thick

You cannot specify the current datastore as the destination datastore, though. It will complete, but it will not convert your VM’s disk format, you have to actually Storage vMotion the VM to a different datastore. It basically validates the destination datastore is where it currently resides and exits without trying to convert your vmdk.

You could then take it a step farther and make a function that supports parameters, like if you wanted to move VMs on multiple datastores, or a given list of VMs to a specific datastore. For instance, you could create something like “convert-vms.ps1” and run it like this

convert-vms.ps1 -vms ("vm1",vm2","vm3","vm4") -destination datastore2 -thick

1	convert-vms.ps1 -vms ("vm1",vm2","vm3","vm4") -destination datastore2 -thick

and it would move all four VMs to datastore2 and convert them to thick in the process. Or something like

convert-vms.ps1 -source ("datastore1","datastore2") -destination datastore3 -thin

1	convert-vms.ps1 -source ("datastore1","datastore2") -destination datastore3 -thin

That would move all VMs from datastores 1 & 2 and thin provision them on datastore3.

If anyone’s interested in the actual script/function, let me know and I can put one together fairly quickly.

Editing vDS Distributed Port Groups with vSphere Distributed Switch PowerCLI cmdlets

I’ve been toying with the vSphere Distributed Switch PowerCLI cmdlets off and on and have had mixed results. It’s worth noting it only works in 32-bit PowerShell, so if you’re wondering why you get do ‘get-vds’, it’s either because the snap-in is not there, or you’re in 64-bit PS. I have a vDS with 17 ‘Networks’, although one is the uplink, and the others are actual distributed port groups. I added “Add-PSSnapin VMware.* -erroraction silentlycontinue” to my profile, so anytime I open PowerShell, I get all VMware snapins.

I was having difficulty because I was getting errors, things weren’t working as I expected, etc. I’ll explain why…

Updated: Finding WWNs for HBAs in ESXi hosts, now with get-vmhosthba

This is an update to my original get-WWN script using Get-View. Get-VMHostHba was pointed out to me by Robert van den Nieuwendijk, vExpert 2012, so I wanted to provide an update to my original post HERE. I attached the ps1 file at the end.

With the addition of get-vmhosthba in PowerCLI, you can get this information somewhat easier. At line 46

$hbas = Get-View (Get-View (Get-VMHost -Name $vmhost).ID).ConfigManager.StorageSystem

1	$hbas = Get-View (Get-View (Get-VMHost -Name $vmhost).ID).ConfigManager.StorageSystem

becomes

$hbas = Get-VMHostHba -vmhost $vmhost -Type FibreChannel

1	$hbas = Get-VMHostHba -vmhost $vmhost -Type FibreChannel

Since that pulls only fibre channel HBAs, the foreach changes to simply $hba in $hbas, and the if statement is no longer needed (line 47-50):

foreach ($hba in $hbas){
$wwpn = "{0:x}" -f $hba.PortWorldWideName
Write-Host -foregroundcolor green `t "World Wide Port Name:" $wwpn
}

foreach ($hba in $hbas){

$wwpn = "{0:x}" -f $hba.PortWorldWideName

Write-Host -foregroundcolor green `t "World Wide Port Name:" $wwpn

}

Here’s the new version –> Get-WWN.ps1

Script to join ESXi 5 hosts to Active Directory for Directory Services Authentication

I’m getting ready to upgrade a ton of our ESXi hosts to 5 and wanted a quick way to join all of them to AD after. I could probably do a fresh install and incorporate this into my ESXi Config Script, that’s a consideration, but for the time being, a script that targets clusters, folders, vDCs, etc, will work. The script can also target individual ESXi hosts, they do not have to be joined to vCenter.

Next release of #PowerCLI will stop on invalid certificates

I’m a little late to the game, but finally got around to installing PowerCLI 5.0.1. Upon connecting to my lab vCenter, I learned of the behavior change that will appear in future releases of PowerCLI. In short, you won’t be able to connect.

By default, it’s unset:

To change that, set the Invalid Certificate Action to Ignore:

You simply type this:

set-PowerCLIConfiguration -invalidCertificateAction "ignore" -confirm:$false

1	set-PowerCLIConfiguration -invalidCertificateAction "ignore" -confirm:$false

It could potentially break all your scripts if you upgrade to whatever’s after 5.0.1.

Function to convert VMs from thin to thick using #PowerCLI & #PowerShell

Most people want to go from thick to thin to save space. I, on the other hand, want to convert my VMs from thin to thick. Thin provisioning buys you time, basically, but what do you do when you’re vastly over provisioned and your VMs are filling up available physical storage? Sure, you can manually go to each VM and use the GUI to migrate them and convert each one to thick. I had a couple hundred that were thin provisioned and needed them converted to thick.

I’ve been moving from 500GB LUNs to 1TB LUNs, so I scripted it out to migrate VMs over, as well as convert to thick using the New-Object cmdlet.