$NTPServers = "10.1.1.1","10.1.1.2"
Get-Cluster "MyCluster*" | Get-VMHost | Sort Name | %{
$_ | Remove-VMHostNtpServer -NtpServer ($_ | Get-VMHostNtpServer) -Confirm:$false
$_ | Add-VMHostNtpServer -NtpServer $NTPServers
$_ | Get-VMHostService | Where-Object {$_.key -eq "ntpd"} | Restart-VMHostService -Confirm:$false
}
VM performance troubleshooting is something every VM Admin needs to do.
Often these can be related to agents running within a VM and often these are set to run at a particular local time.
VDI deployments often have people from different time zones working different shifts connecting to VMs in a central site with the idea that a particular agent task will always run out of hours from when people work. This would obviously not happen if the guest local time zone was not set correctly.
PowerCLI to the rescue and a one-liner that connects to a particular set of VMs and uses WMI to find out what time zone is set.
Get-VM -Location (Get-Folder "Workstations-Call Center") | Where { $_.PowerState -eq "PoweredOn" } | select Name, @{ Name="Time Zone"; Expression={(Get-WmiObject -Class win32_TimeZone -Comp $_.Guest.HostName).Caption}}
Hugo Peeters has a great function for using WMI to get Logged on Users:
http://www.peetersonline.nl/index.php/powershell/oneliner-get-logged-on-users-with-powershell/
This can be easily used in PowerCLI. This can be very useful when you need to do some VM maintenance in a VDI environment and need to find out who is currently logged on and know which VMs are not in use and can be worked on.
$VMs = Get-Cluster "LON_PROD1" | Get-VM | Where { $_.PowerState -eq "PoweredOn" }
ForEach ($VM in $VMs) {
Write-Host "Logged On Users for: " $VM.Guest.HostName
Get-WmiObject Win32_LoggedOnUser -ComputerName $VM.Guest.HostName | Select Antecedent -Unique | %{"{0}\{1}" -f $_.Antecedent.ToString().Split(’"‘)[1], $_.Antecedent.ToString().Split(’"‘)[3]}
}
There are many occasions when you may need to produce a report showing some aspect of your VM environment.
Many companies have various types of inventory databases which grab information from various sources to provide tracking and reporting of the various IT assets.
An example of a database could be one which pulls information from the software inventory system, patch management system, anti-virus console showing latest file update, AD etc. which could show a dashboard view of the workstations and highlight where they are not in compliance to company standards.
As a virtual workstation environment grows there is plently of information from vCenter that would be very useful to gather.
Grouping VMs by VDI groups in vCenter folders so you know how many VMs x department has would be useful to have. For the dashboard view it may be usedful having the VM Tools status. It’s could also be useful knowing which VMs are in which cluster and datastore, what virtual CPU and RAM they have and how big their disks are which can be used for capacity planning, performance analysis and reporting on what is deployed where.
Here are some handy script lines for working out what CDs you have connected which can cause Vmotion to fail.
You don’t always want to disconnect all CDs. If you have .ISOs on shared storage Vmotion will be fine as long as the hosts can both see the .ISO files.
Get the names of VMs with connected CD drives:
get-vm | where { $_ | get-cddrive | where { $_.ConnectionState.Connected -eq "true" } } | select Name
Get the names of VMs with connected .ISOs
get-vm | where { $_ | get-cddrive | where { $_.ConnectionState.Connected -eq "true" -and $_.ISOPath -like "*.ISO*"} } | select Name, @{Name=".ISO Path";Expression={(Get-CDDrive $_).isopath }}
Disconnect all VMs where the CD Drive is connected and it is not an .ISO
$VMs = Get-VM
$CDConnected = Get-CDDrive $VMs | where { ($_.ConnectionState.Connected -eq "true") -and ($_.ISOPath -notlike "*.ISO*")}
If ($CDConnected -ne $null) {Set-CDDrive -connected 0 -StartConnected 0 $CDConnected -Confirm:$false }
or another slightly quicker and dirtier way thanks to commenter José de Alonso
Get-VM | Get-CDDrive | Where {$_.ISOPath -ne $null} | Set-CDDrive -NoMedia -Confirm:$false
If you work on multiple systems and need to use powershell to manage them but they all have their own separate installation it can drive you mad having so many different console shortcuts to launch.
I have 3 at the moment, VMware vSphere PowerCLI, Citrix XenServer PowerShell SnapIn and NetApp’s Data ONTAP PowerShell Toolkit.
Each one installs slightly differently and then runs separately which is a pain.
VMware vSphere PowerCLI installs a PSSnapin and creates this shortcut:
C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -psc “C:\Program Files\VMware\Infrastructure\vSphere PowerCLI\vim.psc1” -noe -c “. \”C:\Program Files\VMware\Infrastructure\vSphere PowerCLI\Scripts\Initialize-VIToolkitEnvironment.ps1\””
Citrix XenServer PowerShell SnapIn installs a PSSnapin and creates this shortcut:
"C:\Program Files\Citrix\XenServerPSSnapIn\XenServerPSSnapIn.bat"
which runs
@C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -PSConsoleFile XenServerPSSnapIn.psc1 -Noexit -Nologo
NetApp’s Data ONTAP PowerShell Toolkit requires you to copy files to the Module Path and then use Import-Module to load the snap-in.
So, Profiles to the rescue……powershell runs a startup script called your profile which is just a text file really.
What I really would like is to have a single profile that launches my session on some computers and starts all 3 snap-ins if they are installed.
That’s not a big ask, is it?
Well, lets start with setting up the profile on this particular computer to launch all 3 snap-ins but be clever and allow it to also be run from anywhere.
My previous post talked about the design of BR and how to script a simple and scalable recovery process for getting as many VMs as you need from a primary site to a BR site when using NFS storage.
When using iSCSI storage it is slightly more complicated as you can’t use one of the benefits of NFS in presenting a read only datastore to ESX hosts in your BR site and having your VMs in the inventory and ready to just power on.
The manual steps would be:
Break the storage mirror.
Rescan the storage on the ESX hosts in the recovery site to pick up the now-visible LUN.
Browse the LUN for all .vmx files and add them into the inventory
Power on the VMs and answer the UUID question that they have moved.
Thanks LucD who has two great versions of a function for importing .VMX files, much better than the old community extension method.
http://communities.vmware.com/message/1317271#1317271
http://communities.vmware.com/message/1270822#1270822
The function is very powerful so it’s worth keeping as a link for using elsewhere.
Also see SRM for free with PowerCLI – Part 2: iSCSI
Working in an enterprise company DR, BR, BCP, whatever you want to call it, is everything. With potentially many thousands of people around the globe, being able to get people working again as soon as possible after a disaster can mean the difference between being in business and going bust.
The best way to do business recovery is to design it from the ground up and make it part of every architecture design you put together. Thinking about the what-if of a disaster after everything is up and running often means you have to start again.
One of the great things about virtual worlds is you can easily (not necessarily cheaply though!) have a separate virtual infrastructure in both locations with shared storage. Simply by mirroring the storage from Site A to Site B you can recover VMs from Site A in Site B very easily without having to have a separate VM in Site B that you need to keep up to date.
This is where VMware’s SRM comes into play. SRM is a fairly powerful piece of software for running and testing your BR. It talks to your back-end storage and can automate the different steps required such as breaking the storage mirror, presenting the storage to your ESX hosts, adding the VMs to your inventory and powering them on.
Sounds great but firstly it is a product you need to pay for and secondly when it came out it didn’t support NFS so PowerCLI (it wasn’t called PowerCLI when we did it) came to the rescue.
I’m going to use the first few posts to dump down some of the PowerCLI stuff I’ve gathered and use regularly.
There are some fantastic scripters out there which I’ve borrowed from extensively such as: Alan Renouf, Luc Dekens, Eric Sloof, Poshoholic, Hal Rottenberg, Hugo Peeters, Mike Laverick and of course the community.
If part or all of a script I post has come from someone and I haven’t acknowledged you, apologies, please let me know and I’ll more than happily direct the glory.
I generally write my PowerCLI in the VESI Script Editor which is just awesome.
Recent Comments