lockenkeyster's Posts

I imagine there is some thread magic you could do to keep track of each upgrade, but would using a simple for loop with a longer pause during the last iteration work for this?: $insParm = ... See more...
I imagine there is some thread magic you could do to keep track of each upgrade, but would using a simple for loop with a longer pause during the last iteration work for this?: $insParm = '/S /v"/qn REBOOT=ReallySuppress"' $vmView = Get-VM | Get-View | Where {$_.guest.toolsstatus -ilike "toolsOld"} for ($i = 0; $i -lt $vmView.length; $i++) {     $vmView[$i].UpgradeTools_Task($insParm)     Start-Sleep -Seconds 30     $i++     $vmView[$i].UpgradeTools_Task($insParm)     Start-Sleep -Seconds 30     $i++     $vmView[$i].UpgradeTools_Task($insParm)     Start-Sleep -Seconds 30     $i++     $vmView[$i].UpgradeTools_Task($insParm)     Start-Sleep -Seconds 300     $i++ }
I believe that adding the -Inflate parameter to each of the Set-HardDisk commands (lines 83 & 87) would accomplish this: Set-Harddisk -Harddisk $disk -Datastore $destinationDS -Inflate -Confir... See more...
I believe that adding the -Inflate parameter to each of the Set-HardDisk commands (lines 83 & 87) would accomplish this: Set-Harddisk -Harddisk $disk -Datastore $destinationDS -Inflate -Confirm:$False
Ok, that's probably the issue. You don't want to add this user to the root group; in fact, whatever default groups are assigned when you create the account is fine. Once the account is created, s... See more...
Ok, that's probably the issue. You don't want to add this user to the root group; in fact, whatever default groups are assigned when you create the account is fine. Once the account is created, select the host, go to the Permissions tab, and add a Permission with the Read-Only role for your new user account. This should give it sufficient permissions to access the performance data via vSphere client and PowerCLI.
I'm not sure how much using RunAsync will speed things up here because the tasks will get queued up on the vCenter Server anyway. The script will end sooner, but it seems that the tasks will stil... See more...
I'm not sure how much using RunAsync will speed things up here because the tasks will get queued up on the vCenter Server anyway. The script will end sooner, but it seems that the tasks will still take roughly the same amount of time to complete. Is there any overlap between the lists of VM portgroups on the destination host and those on the source host? My only thought is to work off of a diff of the two lists. So, instead of unnecessarily removing portgroups that are readded again later, you just don't remove them in the first place.
Ok, thanks for the info. Just so I'm testing with the correct parameters, what rights did you assign to this new account on each host? If Read-Only, can you also try it with Administrator privile... See more...
Ok, thanks for the info. Just so I'm testing with the correct parameters, what rights did you assign to this new account on each host? If Read-Only, can you also try it with Administrator privileges on a single host just to rule out permissions as an issue?
Some of the errors (ignoring the "Could not find" ones for now) look like the Get-Stat cmdlet isn't returning anything when called, resulting in some division by 0 errors. Can you post the ESX/ES... See more...
Some of the errors (ignoring the "Could not find" ones for now) look like the Get-Stat cmdlet isn't returning anything when called, resulting in some division by 0 errors. Can you post the ESX/ESXi build version you are using? I might have to spin up a test environment to see if  I can recreate the error.
You don't have to be logged in as root (although that works if they share the same password). This should also work with AD credentials if your hosts are configured to accept that. If not, then y... See more...
You don't have to be logged in as root (although that works if they share the same password). This should also work with AD credentials if your hosts are configured to accept that. If not, then you will need to create local accounts on each ESX/ESXi host for this purpose. I haven't played around with that setup, but these accounts would likely only need read-only rights on the hosts to get this working.
This should get you the info that you need: Get-VM | Get-NetworkAdapter | foreach ($_) { Write-Host $_.Parent.Name "("$_.Name") type:" $_.Type } But in larger environments it may be... See more...
This should get you the info that you need: Get-VM | Get-NetworkAdapter | foreach ($_) { Write-Host $_.Parent.Name "("$_.Name") type:" $_.Type } But in larger environments it may be helpful to throw the info into a table that you can export later or look at one NIC at a time: $myVMs = Get-VM $allNics = @() foreach ($vm in $myVMs) { $myNics = Get-NetworkAdapter $vm foreach ($nic in $myNics) { $nicInfo = "" | Select "VM","Nic","NicType" $nicInfo."VM" = $vm.Name $nicInfo."Nic" = $nic.Name $nicInfo."NicType" = $nic.Type $allNics += $nicInfo } } $allNics
Like this?: $myDS = Get-Datastore $results = @() foreach ($ds in $myDS) { $dsview = $ds | Get-View $thisDS = "" | Select "DatastoreName","CanonicalName" $thisDS."DatastoreName" = $... See more...
Like this?: $myDS = Get-Datastore $results = @() foreach ($ds in $myDS) { $dsview = $ds | Get-View $thisDS = "" | Select "DatastoreName","CanonicalName" $thisDS."DatastoreName" = $ds.Name $thisDS."CanonicalName" = $dsview.info.vmfs.extent $results += $thisDS } $results
A couple of things to check: Is it possible that there are leftover files on the datastore for VMs that don't reside there anymore, such as old .vmdks taking up space?  You can open up the Bro... See more...
A couple of things to check: Is it possible that there are leftover files on the datastore for VMs that don't reside there anymore, such as old .vmdks taking up space?  You can open up the Browse Datastore browser and compare what you see listed against what is actually running and living on this datastore. Maybe there is another overallocation alarm being applied from a different level in the vCenter tree?  I've seen this in the past, especially after upgrades to vCenter Server.  Having a default overallocation under 100% would be odd though... Good luck
We were recently asked by our storage team to migrate all VMs off of  one array we are using and onto another.  Not being a huge fan of  planning and carrying out a move like this one virtual dis... See more...
We were recently asked by our storage team to migrate all VMs off of  one array we are using and onto another.  Not being a huge fan of  planning and carrying out a move like this one virtual disk at a time, I  decided to take a stab at a datastore evacuation script.  There was  already some know-how out there, so I started poking around and found  some useful posts & threads: http://get-admin.com/blog/how-to/vmware/powercli-evacuate-a-datastore/ http://communities.vmware.com/thread/299279/ My main issue with existing scripts that I found was that they  presumed the entire VM was on a single datastore – not the case in our  environment.  In fact, virtual disks associated with a single VM are  often on different tiers of storage for our customers.  I set out to do  write this code with that in mind, and the result is a script that  simply moves the vmdk’s that exist on one datastore to the destination,  without touching anything I didn’t ask to be moved. Also, giving credit where it’s due, I simply took Luc Dekens’ (LucD) code snippet from the VMware Communities thread on migrating a VM’s  config files and plopped it into a function (migrateVMConfig) in my  code.  Thanks Luc! The current iteration of the migrateDatastore function checks for two criteria before proceeding with the move: The destination datastore is equal in Capacity or larger than the source The Free Space on the destination is greater than or equal to the Used Space on the source The first check can probably be removed at some point, but the second  is kind of a no-brainer – you can’t move actual used space to something  smaller than it’s current datastore unless you are also going from  thick to thin provisioned (which this script does not currently do). I tested this script extensively in my dev environment before  proceeding with any production moves, but please let me know if any bugs  or problems crop up.  Along those lines, if you want to use this script  please do your own testing before using it in production, and always  start with one datastore at a time before progressing to large-scale  evacuations. Usage (from the PS CLI): .\MigrateDatastore.ps1 -VIServer "myvcenter.mydomain.com" -sourceDatastore "DS01" -destinationDatastore "DS02" (originally posted on my blog: Get off my array! (Scripting datastore migrations with PowerCLI))
Would be cool if you could add " | where {$_.PowerState -eq "PoweredOn"} " after $myVMs = Get-VM -Datastore $myDatastore -server $server So we dont get errors on powered off vms. Added!... See more...
Would be cool if you could add " | where {$_.PowerState -eq "PoweredOn"} " after $myVMs = Get-VM -Datastore $myDatastore -server $server So we dont get errors on powered off vms. Added! By the way, is there any way to do the same with the datastores ? Not sure I know what you mean here - you just want datastores with no running VMs to be excluded from the results? If so, yeah, that should be easy enough.
I went ahead and added the rounding to version 3 of the script after I realized that I don't really care that much if a single VM is doing .3 read IOPS.
Sorry, looks like I need to learn how to format for these discussion boards... there should be brackets "[ ]" around "int"
godbucket - I've uploaded a new version of the script that ignores the cert alerts. Also, if you want rounded numbers the easiest way would be to replace the last line in the GetAvgStat funct... See more...
godbucket - I've uploaded a new version of the script that ignores the cert alerts. Also, if you want rounded numbers the easiest way would be to replace the last line in the GetAvgStat function: return $totalIOPS/$samples/20 with this: return ($totalIOPS/$samples/20)
The array that you pass to the -datastores parameter can have multiple datastores in it. For example: GatherIOPS.ps1 -server myvcenterserver.mydns.com -datastores @("DS01","DS03","DS25") -num... See more...
The array that you pass to the -datastores parameter can have multiple datastores in it. For example: GatherIOPS.ps1 -server myvcenterserver.mydns.com -datastores @("DS01","DS03","DS25") -numsamples 90 Currently, the script will only work against one vCenter instance (but gathers data from all ESX hosts managed by that instance). If there is a need to hit multiple vCenter Servers I can modify it to take this in as an array as well.
This script is a work-in-progress, but has come in very handy when I am placing VMs, and their virtual disks, in our environment. Right now, the script scours the virtual environment for VMs & t... See more...
This script is a work-in-progress, but has come in very handy when I am placing VMs, and their virtual disks, in our environment. Right now, the script scours the virtual environment for VMs & templates, then tracks how much space their virtual disks and swap files take up. After adding that all up, it displays (and outputs a CSV of) all of the useful information per datastore, including the “real” free space available, capacity that includes your over-allocation %, provisioned space, and normal free space. In a future (more accurate) version, I plan to also include log files, since those can actually take up significant space. Syntax: .\StorageCapacity.ps1 -server Where -overallocate is the percentage by which you want to overallocate storage (if at all) & the account you run the script as must have at least Read-Only access to vCenter Server and data reader role on the virtualcenter SQL db. (original blog post: http://bit.ly/dx8qIB) http://virtualcurtis.blogspot.com
Thanks guys. @Zsoldier: Yeah, that's why I decided to get the stats from the hosts themselves. Would be a bit more streamlined if stats were up to level 3 across the board and everything happ... See more...
Thanks guys. @Zsoldier: Yeah, that's why I decided to get the stats from the hosts themselves. Would be a bit more streamlined if stats were up to level 3 across the board and everything happened through vCenter, but one of our environments is still at level 2.
Our friendly storage admin sometimes calls me up or sends alert my way from the array when the virtual environment is generating too many IOPS on a particular parity group. From his side, this co... See more...
Our friendly storage admin sometimes calls me up or sends alert my way from the array when the virtual environment is generating too many IOPS on a particular parity group. From his side, this could be happening on any of a number of LUNs that have been presented to our hosts, and he has no way of telling me what virtual machines could be causing the trouble. Through the PowerCLI, I’ve scripted a way to check performance across the environment for the heavy hitters and report that info back. The script takes in an array of datastores, a vCenter Server FQDN, and a number of statistical samples to grab. It tracks down the physical hosts of the virtual machines that reside on those datastores and reports back the IOPS done (read & write) for each of those VMs over the interval specified. The credentials it asks for are a local account on the ESX/ESXi hosts, NOT for vCenter. (Originally posted on my blog: http://virtualcurtis.wordpress.com)
I've been working on a script using the PowerCLI that does something similar; maybe this will help you out? I made a quick post on my blog and linked to the source from there: blog - source... See more...
I've been working on a script using the PowerCLI that does something similar; maybe this will help you out? I made a quick post on my blog and linked to the source from there: blog - source - UPDATE: Sorry, forgot to mention that the credentials the script asks for are a local account on the ESX/ESXi hosts, NOT for vCenter.