As part of the service I’m providing to the client I’m working for, I’ve been developing scripts to both automate the initial deployment of ESXi (Unattended install), which has gone well and finished to the point it needs to be where a PXE boot environment sits on the LAN to automate the entire process from host server network boot to a standalone ESXi host existing on the network. To follow on from this I opted to use PowerShell to provide follow-up configuration to that unattended phase. This then expanded to configuring the vCenter server and auto-deploying VM’s. A lot has changed about my scripts as I’ve learnt more about PowerShell and seen the trends used in writing PowerShell scripts from others on the Internet.
I’ve reached a point where my ESXi follow-on does as much as I need for now, but needs a vCenter in place first, so that has been a recent focus along with a deployment script (we are at a point where the client production environment needs VM’s so I had to escalate that one!). I’ve really learnt a lot about PowerShell these last few weeks and am quite pleased with what my scripts can do as far as completing a lot of timely tasks in a matter of minutes. In the case of the vCenter and VM deployment scripts, as I’ve developed them I’ve thought of more things I’d like them to do so it automated as much as possible and I’ve almost achieved a 100% VM deployment…I think!
The vCenter configuration script takes and empty vCenter server (newly deployed VCSA or Windows based) and populates the datacenters, clusters, resource pools, VM folders and vApps, whilst also setting the cluster HA/DRS and Resource Pool/vApps (to a basic level but has capacity to cover all values possible through PowerShell), all from a single CSV based database. It makes a lot of checks to ensure objects can be created and values can be set to avoid errors, and can account for duplicate resource pool name across clusters when deploying vApps. Folders are created in the right place and not in the ‘Hosts and Clusters’ window. This has been enough to satisfy my need to deploy a production vCenter quickly and allow additional vCenter servers to be configured just as quick as and when necessary.
The ESXi follow-on script completes the customization of the host itself and joins it to the vCenter server, putting into the correct cluster. There is a little more work needed here to eliminate hard-coded information but again, it is at the point where it does what I need easily and quickly.
The VM deployment script has been a challenging one as the VM’s will have 2x network adapters and some will have multiple disks. The template is built with a single C: drive and configured as much as necessary with just one NIC. Therefore I’ve had to figure out how to add disks during the VM build-out and then add additional adapters. I also wanted to configure the 2nd NIC IP before the script finished and this was probably the most challenging part. I have actually only finished this final piece of the jigsaw tonight and suffice to say, it works 🙂 The script itself uses another CSV file holding all critical details for each VM to be deployed. The first phase sets up a unique copy of the Guest Customization Specification, configured in vCenter (I guess I could have created this with PowerShell too!) and applies the primary NIC settings which can then be passed to the VM during phase 2 which is to create the VM itself from the prepared template. The VM placement is set and ensures the right cluster resource pool is used in the event duplicate names exist. I’ve then added the second NIC ready for configuration later in the script because the VM hasn’t been powered on yet! Phase 3 configures the CPU count, RAM, adds additional VMDK’s as necessary (applying the correct storage format), finally setting DRS Automation and HA Isolation Response/Restart Priority (if they are specified). At this point the VM is powered on. The final phase is to set the second NIC IP but the customization hasn’t completed yet so we need to wait. The powered on VM will reboot itself approx. 2 minutes after first power-on to begin the customization and then reboot itself 1-2 more times before completing. We really need to wait until that final boot before trying to set NIC 2’s IP. Therefore I’ve put a loop in where I ping the VM’s custom primary IP (which won’t be active until customization has completed at which point we know the VM is ready). Once a response is received there a further pause to allow the boot process to complete since the NIC becomes active prior to log-on ability (and we need to login to set the NIC), before PowerShell cmdlets are passed to the GuestOS with the local admin account to apply the secondary custom IP details.
That’s it! To be honest, it doesn’t seem a lot to me but the challenge has been to learn and achieve it. I don’t deny I’ve used the expertise of others from their Internet Blogs and forum posts to reach my goal but I can also say I’ve not found any one script out there that does all the things mine do, so I’ve had to use my brain to link everything together 🙂 My scripts are available @ https://drive.google.com/folderview?id=0B6F_8rRvfphJU0RSRlE2QUk2Z2c&usp=sharing