We have had some issues where VCB doesn't clean up after itself everytime it runs so I wrote a quick script that will query all the VM's for current snapshots left over and send an email to me with the name of the VM, Snapshot Name, Description,Date of Creation and Host it is running on.
Follow the comments in the script and change the variables where needed to suit your environment.
We have a very small VMware server population right now as we are just getting started. Consequentially keeping the non-production systems offline after hours to ensure HA resource availability is crucial for us. This script shuts off all VMs NOT in our "production" and "Infrastructure" resource pools.
$serv = Connect-VIServer -Server VC01
$pools = Get-ResourcePool -Server $serv | where-object { ($_.Name -ne "Production") -and ($_.Name -ne "Resources") -and ($_.Name -ne "Infrastructure") }
foreach ($pool in $pools ) {
$vms = Get-VM -Location $pool | where-object {$_.PowerState -eq "PoweredOn"}
foreach ($vm in $vms) {
if ( $vm -ne $null ) {
Shutdown-VMGuest -VM $vm
}
}
}
This is untested for obvious reasons. For the same reasons, i've uploaded it as a txt file instead of as a ps1.
This powershell function should sequentially remove from your VIServer all: snapshots, templates, VMs, resource pools, folders, clusters, datacenters virtual port groups, virtual switches, network adapters, host network adapters, storage adapters, stop all vm host services, remove all hosts, and host accounts.
It's usefulness is limited to those having a test VIServer that needs to be stripped and started from scratch. I don't recommend you execute this function, it's too dangerous, but the evil had to be released...
USE AT YOUR OWN RISK!
Many VMware environments will consist of multiple ESX servers, with multiple HBAs, connecting to multiple SCSI Targets, having access to multiple LUNs, which are used as extents for numerous datastores. In order to be able to use Vmotion, all LUNs should be accessible on all ESX hosts in a cluster. And in order to ensure reliability and availability, each component in the chain will have to be redundant. This amounts to multiple paths to each LUN, from each ESX host. While your environment grows, the number of paths grows exponentially. My script allows you to analyse complex environments and check for missing links, misconfigurations such as a LUN not masked to one of your ESX hosts or a multipath policy that is set to a wrong value.
My Get-StorageInfo script processes all LUNs connected to ESX Servers within a specified VMware Cluster. It builds a custom collection of objects representing these LUNs, with the following properties: VMHost, LUNPath, Policy, Prefer, Datastore, Vendor, Model, VMHBA, SCSITarget, LUNID, LUNKey. The script should be dot-sourced to allow the user to view, filter and sort this collection. The script will check if it is being dot-sourced. The script also prvides the user with two functions for common sorting and filtering tasks, as well as two examples for using them.
Type Show-DatastorePaths for an overview of LUNs and path counts.
Type Show-LUNs for a detailed overview of Luns, which can be filtered by using the following parameters: VMHost, LUNID, Policy, Datastore, Vendor, Model.
Examples:
Show-LUNs -Datastore PRD -Policy mru #Finds LUNs where the datastore name contains PRD and the policy is set to MRU
$LUNCollection | Where{$_.Datastore -eq $null} | Group-Object LUNID #Shows LUN IDs that have no datastore name (e.g. RDMs or unused LUNs)
A bit more info on the inner workings of the script:
In order to get all LUNs via all different paths I go through a set of nested loops. First looping through all VMHosts in the cluster, then looping through VMHBAs, then SCSI Targets and finally LUNs.
Not all properties I wanted to use are available within these loops. Therefore, for each VMHost a collection is built containing the relationship between Datastore names and Extents (in the form of a LUN path e.g. vmhba1:0:123). This allows the script to link the datastore name to those LUN paths that are actively used. The multipath policy and preferred path and the Vendor and Model of the LUN storage device are also found by using the LUN path.
After looping through all of the above, only a fraction of the LUN references have all the properties filled in: the actively used ones. Next, the script loops through the entire collection of LUN references in the collection, matching references to the same LUN by comparing the LUNKey or UUID and copying the properties that were empty.
That's a lot of looping, I hear you think. That's right. And it will take some time to complete. In our environment it takes about ten minutes generating the entire collection of 1440 references to different LUNs. But the result is a very rich array of items which - using the awesome power of Powershell - can generate a lot of usefull information for your environment.
Enjoy!
UPDATE:
I have modified the script to include the following:
Easy to use input prompt and menu eliminate the need to edit the script before use.
Improved progress indicators now show percentage completed for each step.
Advanced logic determines the discrepancies in storage configuration between hosts. These potential configuration errors are displayed on screen with all relevant properties of the involved LUNs / Datastores!
Test the script by adding a LUN to only one ESX server in a cluster. This misconfiguration (which will cause VMotion of a VM with files on that LUN to fail!) should be spotted by the script.
UPDATE 2:
Added support for Folders. Added menu choices that allow you to run the script against all VMHosts in a Folder or in a Cluster or even ALL VMHosts in your VC Server.
Firstly, I wanted you to know that I only started with PowerShell around a month ago when I saw the cool things you were doing with the beta of the VI toolkit, so not only have I been learning the toolkit but also PowerShell, this will hopefully excuse the basics of my code and I am sure that the experts will find a better (and faster) way of doing it !
Scenario:
You have convinced your IT Manager that VI3 is the best virtualisation product compared to the others out there on the market (that was the easy bit). You have told him how much money you will save him and how environmentally friendly his server room will now be. He has dusted off his corporate wallet and agreed to pay for.
Your "pointy haired" IT Manager has asked for a weekly report of what is virtualised and an overall status of what is happening in this new wonderful system, whilst you are working 24hr shifts just to get the downtime for servers whilst your users sleep you do not have time to keep creating reports.....Enter my script !
Answer:
You could send him a bunch of html emails and csv outputs but your manager would only need help importing them and help understanding what each file is. This script not only outputs all the results straight to MS Word but also adds nice colourful graphs and pie charts (which we all know makes managers happy). The script can be easily added too, to enable further output utilising the functions.
It can also email the results directly to the manager and maybe be used in a scheduled task ?!
On a personal Note:
This has really given me a reason to start to learn PowerShell (I have been meaning to for ages) and also learn how to use the fantastic new VI toolkit, if nothing else I have gained the valuable experiences of learning PS and the toolkit. Thanks to the creators.
Usage:
Report.ps1 YOURVISERVER
You will need MS Word and the Office Web Components (script will tell you where to download if not installed)
This script takes a varied amount of time to run and only reads data, no configuration changes are made at all, obviously the bigger system the longer it will take, not that you would notice if it was a scheduled task.
The email areas are currently commented out at the end awaiting customisation if needed.
Sorry if it doesnt work on your VI, I have not been able to test as extensively as I would have liked due to only having one VI.
Office XP/2003/2007 tested.
This Script is to determine what services are running on what vm's in a VI organization
This is very handy when you have many vm's running all types of services - and can point out a rogue service you may not want to have in your VM's
This script will require:
An administrator account to remote servers that are in the VI as WMI is used to obtain information.
Powershell and MS Excel.
I get a list of services from each vm and output these along with the VM (IP information and vmnetwork for NICS.)
There is a list of services that are excluded by default, this can be disabled if needbe, thus allowing you to get a better view of what services are installed and running on the vm's.
I use WMI to obtain information from the servers - for this to work correctly you need to have administrator access to all of the servers and for the script to be run under this account and the servers need to have WMI/RPC running.
So some webservers etc. may not show any services as the app can't talk to them (in some ways if it can it may be a security problem)
In my environment I run this script under an account that is the Enterprise Admin in the root domain for the Active Directory. Or any account that has administrator access on all of the servers.
The description is obtained as well as the status of each service to further assist the user to determine what a service is.
Future versions will:
Create seperate excel sheets for each ESX server - The vm's will then be displayed on those sheets as well as one consolidated sheet.
ESX services will be displayed on each sheet.
A port Scan will be completed on the ESX server as well as each vm - thus giving a full idea of what ports are open on the vm's
#This is a script to failover multiple groups of virtual machines.
This is for a Virtual Infrastructure based in two datacenters. Each datacenter has a SAN with a series of LUNs that are mirrored (SRDF)to the other location.
There is one VirtualCenter that is a VM that this script can be run against. There is a seperate procedure to failover the VirtualCenter VM.
This carries out the following actions on each virtual machine in the folders specified:
Attempt to shutdown the OS
Perform a Power Off of the VM
Pause to allow other procedures to be run to failover the storage and VLANs
Get the Hosts to Rescan for VMFS partitions
Remove the VM from the Inventory
Add the VM to the Inventory but against an ESX host in the target datacenter.
Perform a Power On of the VM
Usage: & .\VMFailover.ps1 Mode Datacenter Folder1 etc..
Where:
Mode is either DEMO or LIVE - (LIVE is the only mode that will execute commands).")
Datacenter is target for the virtual machines to failover to (either "$dc1" or "$dc2").
Folder1 (Folder2, etc) are the VirtualCenter folders containing the VMs being moved.
This script assumes you have already connected to VirtualCenter with Get-VIServer
It also assumes that the user has full administrator rights to the Datacenter.
This script and config file is used in our environment to clone a base image on a netapp 3020 cluster with NFS and a-sis. Cloning is done parallel on all systems mentiond in the configuration file. Afterwards sis is running on the netapp to gain storage. Different types of vm's can be specified in the configuration file and in our situation vm's disk mode is set to non-persistant. Steps are listed in the script. Good to know is that a script within the vm will force a shutdown so the process will contiue.
Sjaak
Need to add or expand a LUN to all the hosts of a cluster? This simple script can save you a lot of time if you are using the GUI to do a rescan on a largish cluster. This script can easily be adapted to rescan on specific clusters or hosts.
Change line 1 to point to the correct Virtual Center server.
Enjoy
-Chris Summers
This script was created out of a motivation of laziness. Since VM's proliferate so fast, most backup and disaster recovery solutions are a pain in the ass because you have to manually add and remove virtual machines to their backup processes. What if there was a way to automatically add and remove VM's to a backup solution simply because of where they are located in Virtualcenter? What if I had an automated DR solution to removable USB hard drives for my smaller clients that was FREE?
Hence this script. This script dynamically backs up all VM's in a particular Virtualcenter folder using VCB, and drops them out to a USB hard drive for disaster recovery purposes. If I don't want a VM backed up anymore, I simply take it out of that folder.
Note that this also leverages the new networked method of VCB, so YOU DO NOT NEED A SAN AND DIRECT ACCESS TO THE LUNs.
The script is also flexible enough so that if you do have the SAN VCB configuration, you can do LAN-free backups with this method too.
Note that the query here is just an example. Any way you can return a list of VM's, you can give it to the backup-vm cmdlet.
Some examples that come to mind:
Backup all virtual machines with disks under 500MB in size
Backup all virtual machines created after July 1st
Backup all virtual machines with "Prod" in their names
Backup all virtual machines with a custom attribute defined called "BackMeUp" set to true
Backup all virtual machines currently residing on a particular host, cluster, or datacenter.
This script took me about 8 hours, mostly because I was learning how to do script cmdlets and dealing with all the incompatabilities/breakage of CTP Powershell releases as well.
The task evolved into my first foray into the new Script Cmdlets in Powershell v2. They're so easy to make I went wild and wrote a near-complete wrapper to VCB. Cut and paste the "cmdlet" section out of the code and put it in your profile, and you can now use the Backup-VM cmdlet.
Install onto a server or workstation with the prerequisites defined in the script (VCB, Powershell v2 CTP2, VI Toolkit v1.0)
Edit the parameters of the script to suit your environment. BE VERY CAREFUL WITH VMBackupDestination
Run to test, then set up as a scheduled task on a daily interval.
Example Screenshot:
Background:
Current Environment
Primary Datacenter located in New Orleans, La. running VMWare 2.5.4 with an EMC CX3-80 backend.
Backup Datacenter located in Dallas, Tx. running VMWare 2.5.4 with an EMC CX3-80 backend
45mb point to point connection running between sites.
All VMWare LUNs setup to replicate using Mirrorview/a with a policy of Time finished +60 minutes schedule.
60 luns with 8tb of data in use and mirrored between the sites.
Based on our Corporate, Disaster Recovery policy, we begin the process of moving our environment from New Orleans to Dallas once Level X is reached. Level X is defined as a hurricane with winds of X, and landfall expected within X hours.
Once Level X is reached, we begin the process of moving our servers to our secondary site, using the following high-level steps.
Run vb script which will update all ip addresses of the current vm's to a network range that is already configured at the secondary site.
Manually shutdown all vm's in a specific order, with our virtual SQL server being last.
On each ESX server, run our "copy config" script which copies all currently registered VM information to each ESX server's partner server at the other location.
Manually remove the luns from the New Orleans EMC VMWare Storage Group
Manually sync each luns remote mirror group
Manually set each mirror to manual sync policy to ensure that the primary location stays "pristine" until we have successfully restarted at secondary site and tested by for replicating the changes in the reverse direction.
Once each mirror is synced, promote the secondary image.
Manually add each lun to the Dallas EMC VMWare Storage Group
On each ESX Server, run the "register vm" script to register the vms based on the information that was copied in one of the previous steps.
Reboot each ESX server, so that the VMs can auto-restart, rebooting the one with SQL first.
With this configuration, there are two major issues.
Since we are changing the IP addresses of the VMs and up dating DNS, some of our remote sites may not see the updated addresses for anywhere from 4 to 6 hours.
LUNs were not layed out to allow for Tier roll over. All luns have to finish replicating before we can start any servers up. We can still get our servers restarted in less than 4 hours, but all servers are down until all data is replicated.
SAN work requires a lot of manual steps.
About 2 weeks ago we started the build out of our new VMWare 3.5 environment. We had the following high level goals.
No ip address changes
Roll of servers based on a priority design
Remove as many manual steps as possible.
Ability to run Production systems at both sites with the ability to move either site if necessary.
Single script regardless of site or direction of move
Configuration of New Environment
VMWare 3.5
EMC CX3-80
Tiered configuration, which each Tier being assigned it's own LUNs
A New Orleans production set of servers and a Dallas set of servers, with each having it's own set of tiers, luns and subnet
Single Script that can move set in a priority fashion to either side, with minimal user steps.
Still requires manually moving subnet, but takes about 5-10 minutes to complete the required steps. (NO VM ip address changes needed)
Attached files
Business Continuity Script Assumptions.doc - This file contains all assumptions of our design and some script requirements.
SAN_Information.csv - This file is an input to the script and documents the EMC configuration for each VMWare Datastore. This information must be accurate for the script to work. The script includes a menu option 99, which allows the testing of the "move" of a lun before it is used in production. This will allow us to validate the information in the csv file
Business Continuity.ps1 - The actual Script file. It includes a number of functions that perform the following goals.
Run_Navi_Cmds - Input is primary SAN location and Datastore that script is actively working with. Will perform the following actions.
Move the lun associated with this datastore out of the primary san's storage group
Sync the mirror associated with this lun with the secondary image at the secondary site
Once synced, will promote the secondary image to primary
Once promoted, will add the new primary to the ESX storage group at the secondary site
Determine_Tier - used by other functions to determine which tier is being actively worked on.
Determine_Move_Direction - Let the user define which Data Center is primary and which group of servers is being moved. It will also create the files holding the each tiers VM and datastore information
Display_Tier_Datastores - Verifies that any Datastores in use by a given tier is not being used by VMs in another tier
Delete_VMs - will allow user to pick tier being worked on, using the vm tier file, will try and shutdown any powered on VM, once powered off, will remove VM from inventory. Once all VMs are removed, will use the tier's datastore file to run the Run_Navi_Cmds function for each datastore in use.
Register_VMs - will allow user to pick tier being worked on, using the vm tier file, will try register all VMs on the appropriate ESX server at the other site
This is an active on going project and our new VMWare 3.5 environment has not been moved to production. We have successfully tested all aspects of our new design without issues. However, we are not finished our testing and will likely be adding additional features to this procedure.
For example, we will probably add to the Run_Navi_cmds function a routine to set all mirrors to manual (no auto syncing). As a policy, we do not replicate from the new primary site to the original primary site until after we have successfully restarted all machines. This gives us a rollback option if we have startup issues. We will also add a menu option to allow us to put a tiers mirror back in auto once we have successfully restarted the VMs at the new primary site.
Based on our preliminary testing, we should see a big improvement in our failover process. For our Tier 1 servers, we expect them to be down no more than 30 minutes once we start our roll process. This alone will allow our upper management to have access to email, blackberry's and other critical data 3 hours faster than our current system setup. During a hurricane event, 3 hrs can be significant
Use at your own risk. This script was tailored for a very specific setup and having a script manipulate your SAN can cause serious issues.