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…
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…
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.
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.
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.
Just thought I’d share…
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
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:
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
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
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.
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…
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
1 |
$hbas = Get-View (Get-View (Get-VMHost -Name $vmhost).ID).ConfigManager.StorageSystem |
becomes
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):
1 2 3 4 |
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
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.
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:
1 |
set-PowerCLIConfiguration -invalidCertificateAction "ignore" -confirm:$false |
It could potentially break all your scripts if you upgrade to whatever’s after 5.0.1.
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.