For my 100th post, I thought I would put something totally different up. Introducing PowerCLI bot!
PowerCLI Bot
I recently purchased a Wacom Bamboo tablet and have been doodling around with it – last night I decided to create a little bot for a custom 404 error page I would like to set up for Shogan.tech. I was looking at the PowerCLI logo at the time and thought I quite liked the colour combination. Anyway, things progressed and I thought I would create a little “PowerCLI Bot” as I have recently been thoroughly enjoying working with PowerCLI and PowerShell.
I’ll be changing him a bit for my custom 404 error page so keep an eye open for his distant cousin 🙂
This is a little bit of a fun project I have been working on in bits of spare time I find. It is all written in PowerCLI 5.0 / 5.1 / PowerShell and the GUI was laid out using Primal Forms Community Edition.
Updates (17-02-2013) – version 1.3:
Hosts are retrieved using a new method (for both backup and restore options)
Updates (29-12-2012) – version 1.2:
Added ESX/ESXi host validation into utility – will now test that the host is valid and either connected or in maintenance mode before attempting backup or restore (See the script’s new “Check-VMHost” function for those interested)
Minor UI improvements
Updates (29-10-2012) – version 1.1:
This utility has been tested on ESXi 5.1 Hosts and confirmed to be able to successfully create a backup archive file of these.
Be sure your DNS is working correctly on the system you run the Backup utility on – it relies on DNS to find your ESXi hosts as they are named in the dropdown when you select the host to backup. (See comments for troubleshooting)
Restore to new hardware (force restore) option added
Fixed labels and connection box label description
What it is essentially, is a GUI that allows you to Backup ESXi 5.0 or ESXi 5.1 hosts to a destination of your choice on a local drive. It also allows you to restore ESXi Host configuration bundle backups taken, to other Hosts. I had other plans to integrate cloud storage options in (Amazon S3) as a backup target, but I thought that this doesn’t really offer anything valuable and I would just keep it relatively simple for now – therefore I have disabled this functionality. The PowerCLI script is fairly long – and I know there are plenty improvements I could make to better it and shorten the code, but for now it does the job. I have added various catches for exceptions / errors so you should get visual feedback if you have entered an invalid path, or username for example.
Anyway, hopefully this proves useful to some! As always, take care using the backup / restore functionality of this utility. The restore functionality works by first putting the ESXi host into Maintenance mode (if it isn’t already in this mode) and then applying a backup bundle to the host (Restore). The Host will reboot immediately following this. The Backup and Restore is implemented using Get-VMHostFirmware and Set-VMHostFirmware cmdlets so you can read the help descriptions for an idea on how exactly these work. The Host Backup Bundles are stored in a path of your choice and when restoring from a path the cmdlet works by looking for a bundle filename that matches the name of your ESXi host selected to restore to. Note that the file browser module I have implemented here (used to select paths) is a modification of the work done by Ravikanth Chaganti on his PowerShell Help Browser GUI. I simply adapted his code to list the contents of local drives in a tree view instead of PowerShell Help cmdlets. The only limitation here is that I have not implemented code to browse further than one level into the root of each drive. If you can provide this modification yourself, please feel free to contribute in the comments! I have just not spent the extra time to do this myself yet.
Here are a couple of quick screenshots of the Utility / GUI:
An interesting thread appeared on the VMware Community forums today under the PowerCLI section where someone asked how to find all the svMotions for the past month. LucD answered the post with the solution to get the events listed out for svMotions. I tried this out in my own environment (first of all I datastore migrated (svMotioned a couple of VMs to make sure there would be some events to find). However, I didn’t get any results back. At first I thought this may be because the event names had changed between vSphere 4 and vSphere 5.
After some looking into the last 5 events that had run by using “Get-VIEvent -MaxSamples 5” and looking at the .Info section for the svMotions, I found that their Info.DescriptionId sections were showing as “StorageResourceManager.applyRecommendation” rather than “VirtualMachine.relocate” as LucD’s script had indicated they should be. After digging some more this evening, I realised that maybe the difference was down to the fact that I was svMotioning VMs between Datastore Clusters, rather than between normal Datastores (not part of a DS Cluster). I tried svMotioning a VM to a normal Datastore, and low and behold the event’s Info.DescriptionId now appeared as “VirtualMachine.relocate”!
So the difference is kind of related to the vSphere edition (in the way that you only get SDRS / Datastore Clusters in vSphere 5. More specifically, the task/event difference is seen when using Storage vMotion to move a VM between two Datastores or two Datastore Clusters.
Migrating VMs Between two Datastore Clusters, you see the event “Apply Storage DRS Recommendations“
Migrating VMs Between two normal Datastores, or from a Datastore Cluster to a normal Datastore (or vice-versa) you see the event “Relocate virtual machine“.
Here are some screenshots to illustrate what I mean:
Recent Tasks - differences between the two svMotion scenarios
PowerCLI - listing both svMotion scenario event types
Here is the PowerCLI script used to list both types of events if you are using both (or just one of) the Datastore types – i.e. Datastore Clusters or normal Datastores. It is based off LucD’s script in the first post of this thread on VMware Communities, but just modified to also show the “Between Datastore Cluster” types of svMotions too.
Welcome session attendance - Photo credit - Chris Kranz (@ckranz)
Today’s meetup was the first London VMUG that I have attended. In the past they have unfortunately landed up on days where work commitments took precedence. Running a few minutes late due to a long walk from Bank Underground Station to the venue, I arrived (to my luck) to find that the Introduction had also kicked off a few minutes late, setting most events forward fifteen minutes. I snuck in through a door near the back to listen to the welcome session.
First Sessions of the morning
Attendance was good from what I saw today – all the sessions were quite full and well attended. Symantec did an interesting presentation on ApplicationHA – a talk followed on by a live demo showcasing Application High Availability. The demo entailed bringing down the SQL Server Instance on a VM at first, allowing ApplicationHA to restart the service to sort it out again. This was followed on by another demo – deleting the entire Database and allowing ApplicationHA to pick up the problem and sort out SQL Server by leveraging Backup Exec to restore the Database. Symantec were also kind enough to offer up some NFR licenses for lab/testing use at the end of their presentation. Its a shame I didn’t get a chance to visit their stand during the break, as I was keen on taking a closer look at this in my own home lab environment.
Next up Chris Kranz and Alex Smith did an informative and interesting set of sessions entitled “Would you like fries with your VM?” and “DevOps & Service Management” respectively. They were interesting talks involving some interesting discussion around the traditional “IT Admin” role, compared with the “Virtual Admin” and “Cloud Admin”. Summing up – IT professionals should stay on top of their game and adapt to survive in this ever evolving industry! Alex also shared some interesting experiences and chatted about DevOps and Service Management along with a few other acronyms – determined to drill these into everyone’s head!
During the break I was able to meet up with Gregg Robertson and Jonathan Medd – there was some interesting chat in the short break, after which the next set of sessions began.
Midday Session
This was a set of sessions that conflicted for me – I was really keen on both. I have had a brief look at Auto Deploy before (whilst studying for VCP5), but I also really wanted to see the VMware View session (End User Computing : Today & Tomorrow – Simon Richardson). I ended up attending Alan Renouf and Max Daneri‘s “How to build 1000 hosts in 10 minutes with Auto Deploy” session – there were quite a few slides to go through, but a good overview of the PowerCLI cmdlets used for setting up Image Profiles (working with VIBs), Rule Sets and Auto Deploy in general was given. Max then handled a great demo showcasing Auto Deploy at work.
Post Lunch Sessions
I went to the “Stop the Virtualization Blame Game” session by Xangati (Ben Vaux) next. This was of interest to me, as a couple of weeks ago I deployed the free “one host” Xangati VI monitoring appliance in my lab at home. There were unfortunately a few issues with the projector in our room, but there was still a good talk about how the product works and some interesting questions were answered by the team. Xangati also had a demo set up in the main vendor / lunch area for live demos throughout the day. The product aims to give SysAdmin’s a “single pane of glass” view of the entire VI / VDI environment – where everything can be monitored and looked after. They monitor stats realtime and also offer a handy “record” feature which allows events / issues in environments to be captured, and replayed later on to see what went wrong. Interesting stuff, and I’ll definitely be playing with this product further in my home lab.
The next session I attended was the “Private vCloud Architecture Deep Dive” with Dave Hill and Aidan Dalgleish. This was an interesting and fairly in-depth session discussing the whole VMware ecosystem: vCloud Director 1.5, vShield, Chargeback etc etc. A “reference architecture” was presented on and discussed along with the three network pool methods and their various pros and cons (VLAN-backed, Port group-backed and vCloud Network Isolation Backed (VCNI)). I also wanted to attend Michael Poore’s session on Orchestration, however these two sessions conflicted and I unfortunately had to decide at the last minute as to which one to view!
The final session had me attending the Embotics lab – I had a quick try out of their V-Commander product to see what benefits it offered. I really wanted to see the Cisco UCS presentation so I did unfortunately miss this one. However I will definitely be catching up on this with the slides that will hopefully be made available soon. Gregg Robertson also did his VCP 5 Tips and Tricks presentation, which I hear went down well – I skipped this one as I was lucky enough to fit in an exam and get my VCP 5 done earlier on this month. Whilst on the topic of VCP’s Jonathan Medd surprised everyone as he casually snuck off during lunch to Global Knowledge to write his VCP 5 exam… and passed!
Ending off with vBeers just down the road, I managed to catch up and have some great conversation with a few other guys, including Gregg Robertson, Jonathan Medd, Darren Woollard, Jeremy Bowman, Michael Poore et-al (sorry to those whose names I omitted i.e. fogot!) All in all, a great day was had with some interesting content!
In the last post [Part 1/2], we prepared our VSA, created a management group and cluster in the CMC, and then initialized our disks. Next up, we’ll be creating a Volume which will be presented to our ESXi hosts as an iSCSI LUN. Before we do this though, we need to make sure our hosts can see this LUN. Therefore we’ll be making entries for each of our ESXi hosts using their iSCSI initiator names (IQNs).
Preparing your iSCSI Adapter
If your ESXi hosts don’t already have a dedicated iSCSI adapter you’ll need to use the VMware Software iSCSI adapter. By default this not enabled in ESXi 5.0. This is simple to fix – we just need to get it added. Select your first ESXi host in the Hosts & Clusters view of the vSphere Client, and click Configuration -> Storage Adapters -> Add -> Select “Add Software iSCSI Adapter”. Click OK to confirm.
Now we need to find the IQN of the iSCSI adapter. In the vSphere client, select the iSCSI adapter you are using and select Properties on it under Storage Adapters. This will bring up the iSCSI Initiator Properties. Click the Configure button and copy the iSCSI Name (IQN) to your clipboard.
Getting the iSCSI adapter IQN using the vSphere Client
Quick tip: you can also fetch your iSCSI adapter information (including the IQN) using esxcli. Login to your host using the vMA appliance, the DCUI, or SSH for example and issue the following command, where “vmhba33” is the name of the adapter you want to fetch info on:
esxcli iscsi adapter get -A vmhba33
Getting the iSCSI adapter IQN using ESXCLI
Configuring a Server Cluster and the Server (Host) entries in the CMC
We’ll now create “Servers” in the HP CMC which are what we’ll be adding to our “SAN LUN” later on to allow our ESXi hosts access. In the CMC go to Servers and then click Tasks -> New Server Cluster. Give the Cluster a name and optional description, then click New Server. Enter the details of each ESXi host (Click New Server for each host you have in your specific cluster). For each ESXi host, the Initiator Node Name is the iSCSI Name, or IQN we got from each ESXi host in the step above. The Controlling Server IP Address in each case should be the IP address of your vCenter Server. For this example we won’t be using CHAP authentication, so leave that at “CHAP not required”. Once all your ESXi hosts are added to the new cluster, click OK to finish.
Creating a new Server Cluster and adding each ESXi host and it's corresponding iSCSI Names/IQNs
Creating a new Volume and assigning access to our Hosts
Back in the CMC, with our disks that are now marked as Active we’ll now be able to create a shiny new Volume which is what we will be presenting to our ESXi hosts as an iSCSI LUN. Right-click “Volumes and Snapshots” and then select “Create New Volume”
Enter a Volume Name and Reported Size. You can also use the Advanced Tab to choose Full or Thin provisioning options, as well as Data Protection level (if you had more than one VSA running I believe).
Now we’ll need to assign servers to this Volume (We’ll be assigning our whole “Server Cluster” we created earlier to this Volume to ensure all our ESXi hosts get access to the volumen. Click Assign and Unassign Servers, then tick the box for your Server Cluster you created and ensure the Read/Write permission is selected. Then click OK
Assign the Server Cluster to the Volume for Read/Write access
Final setup and creating our Datastore with the vSphere Client
Go back to the vSphere client, go to one of your ESXi hosts, and bring up the Properties for your iSCSI adapter once again. We’ll now use “Add Send Target Server” under the Dynamic Discovery tab to add the IP address of the P4000 VSA. Click OK then Close once complete.
You should be prompted to Rescan the Host Bus Adapter at this stage. Click Yes and the Rescan will be begin. After the Scan is complete, you should see your new LUN is being presented as we’ll see a new device listed under your iSCSI Adapter (vmhba33 in my case for the Software iSCSI adapter).
New device found on the iSCSI Software adapter
Now that everything is prepared, it is a simple case of creating our VMFS datastore now from this LUN for our ESXi hosts to use for VM storage. Under Hosts & Clusters in the vSphere Client, go to Configuration, then Storage. Click Add Storage near the top right, and follow the wizard through. You should see the new LUN being presented from our VSA, so select that and enter the details of your new Datastore – Capacity, VMFS file system version and Datastore Name. Finish off the wizard and you are now finished. The new datastore is created, partitioned and ready to be accessed!
Add Storage Wizard
Complete - the new datastore is added
Well, that is all there is to it. To summarise, we have now achieved the following over the course of these two blog posts:
Installing and configuring the P4000 LeftHand VSA
Setting up the CMC
Creating a VSA Management Group
Creating a VSA Standard Cluster
Creating Servers entries in a new Server Cluster for each of our ESXi hosts to be presented the storage
Creating a LUN / Storage Volume
Configuring the ESXi hosts to find our VSA in the vSphere Client
Adding the Storage to our ESXi hosts and Creating our VMFS Datastore using the vSphere Client
To conclude, I hope this series has been helpful and that you are well on your way to setting up iSCSI shared storage for your VMware Cluster! As always, if you spot anything that needs adjusting, or have any comments, please feel free to add feedback in the comments section.
