Monthly Archives: April 2013

Backing up your vCenter DB – all three of’em

three-fingersWait!  What!  3!?!?!  Yes, you read correctly!  While in the days of vCenter 5.0 and below we only had to worry about 1 database, the release of 5.1 has tripled that!   This is something I hadn’t even thought about until recently attending a vBrownbag put on by Justin King (@vcenterGuy).

So there’s the SQL database from vCenter right – ok – no big, I know about that one and am backing it up – KB article on how to do that.

Then there is the SSO database – no problem, I knew about that one as well since I had to create it when I first upgraded to 5.1.  Again it’s a MS SQL DB, doesn’t change that much –  which is easy enough to backup…

But then Justin started talking about the Inventory service – remember, that’s the third requirement you had to install when upgrading.  Well guess what?  It has a database too!  It’s not SQL at all – it’s sitting on your vCenter Server in xDB format.  My first thought was what is even in this database – I can’t browse it like I can the SQL databases (or I just don’t know how to).  What I can gather from the What’s New docs and VMworld presentations the Inventory database holds things such as a read cache of all the objects that are accessed within the vSphere Web Client and all of your tags and categories that are setup from vCenter.  I’m sure there’s more but this is all I can find.

However back to my main objective, how do I back this thing up?  A little digging around and I found this KB article on how to backup/restore your vCenter Inventory database.  Basically it’s as follows.

Backing up the inventory database (WINDOWS)

  1. Navigate to the Inventory scripts folder (c:\Program Files\VMware\Infrastructure\Inventory Service\scripts)
  2. Run the following
    • backup.bat -file backup_filename

Restoring the inventory database (WINDOWS)

  1. Navigate to the Inventory scripts folder (c:\Program Files\VMware\Infrastructure\Inventory Service\scripts)
  2. Run the following
    • restore -backup backup_filename

So utterly simple yet so not talked about 🙂  Wait – but what if I’m using the vCSA?  Am I out of luck?  Absolutely not!  Use the following…

Backing up the inventory database (Linux)

  1. Navigate to the Inventory scripts folder (/usr/lib/vmware-vpx/inventoryservice/scripts/)
  2. Run the following
    • ./backup.sh -file backup_filename

Restoring the inventory database (Linux)

  1. Navigate to the Inventory scripts folder (/usr/lib/vmware-vpx/inventoryservice/scripts/)
  2. Run the following
    • ./restore.sh -backup backup_filename

So there you go!  You can now sleep at night knowing you aren’t going to lose all of your hard work setting up those tags!  Moral of the story – Pay attention and participate in the vBrownBags – there is always some great information and learning to be had.

My First vCenter Orchestrator Workflow – Part 4 – A look at the Powershell Plug-in

Orchestrate-FacilitateAlright!  So far throughout this series of posts we have installed, configured and setup vCenter Orchestrator; as well as created and tested the integration between both vCO and the vSphere Web Client.  So what’s next in my venture?  Well if you can remember back to Part 1 of the series I set out on a quest to develop a workflow that would take an un-configured host and go through a series of tasks to create datastores, rename networks, setup hostname, etc…  Basically configure it the way I wanted.  Now there are built-in workflows in vCO to do this, however I had already done this work inside of a PowerShell script – so my main goal was to get vCO to execute that script.  And this leads us to part 4!

So first off as I said above there are a ton of great built in workflows inside of vCO that can do pretty much anything.  Some things however, such as the ability to run a Powershell script, are missing!  Thankfully there is a thriving developers community built around vCO and it’s SDKs allowing third party vendors to release their own sets of workflows in the form of a plug-in.  So as you probably guessed by now we will need to install a plugin to handle our Powershell script execution.

This plugin is called the vCenter Orchestrator Plug-in for Microsoft Windows Powershell and can be found over on VMware’s site.  You will need to download this file.  Once you have your hands on the vmoapp file we need to go into the vCenter Orchestrator Configuration page (https://IP_OF_vCO:8283/) to install it.  Select Plug-ins from the left hand menu, then browse down to the Install new plug-in section.  Upload your file and click ‘Upload and install’, accept the EULA and away you go… If you browse back to the main Plug-ins page you will notice that it states the plugin will be installed at the next server startup; so if you wish you can do this task manually by going to Startup Options -> Restart Service.

vCO-InstallPlugin

At this point we can fire up our vCO client.  Having a look in the Library of workflows we can now see a PowerShell folder.  Expanding this out further let’s us see some of the workflows that come packaged with the plug-in.  So we now have a few configuration steps we need to go through before executing scripts with this plug-in.

First off we need setup a PowerShell host.  A PowerShell host is simply a Windows machine with Powershell installed located somewhere in your environment that will handle the storing and executing of the scripts.  There is a great article on all of the steps here but I will go through explaining them all as well.   Keep in mind this might not be the most secure of ways to go about everything – but this is simply a lab so I’m not too worried – for those concerned w/ security implications check out the full lengthy thrilling winrm read on the msdn 🙂   

So, once you have chosen which machine you would like to be your Powershell host go ahead and drop to a command prompt on that machine and run the following list of commands.

  • To create a winrm listener and open any required firewall ports
  • winrm quickconfig
  • To enable kerberos authentication
  • winrm set winrm/config/service/auth @{Kerberos=”true”}
  • Allow transfer of unencrypted data – told you wasn’t the most secure 🙂
  • winrm set winrm/config/service @{AllowUnencrypted=”true”}
  • Up the max memory per shell – I needed to do this to get things working
  • winrm set winrm/config/winrs @{MaxMemoryPerShellMB=”2048″}

And there we are!  Things should be setup fine now on our host end to allow the connections from our vCO server.  Now we need to configure kerberos on the vCO end of things.  To do this you will need to console into your vCO server and get on the command line there – hope your comfortable with vi 🙂

Basically we need to create a file under /opt/vmo/jre/lib/security called krb5.conf – to do so simply

cd /opt/vmo/jre/lib/security
vi krb5.conf

This file will need to look as follows – obviously change to fit your environment – if you happen to be using an default configuration of the autolab then you are good just to copy the following…

[libdefaults]
default_realm = LAB.LOCAL
udp_preferences_limit = 1
 
[realms]
LAB.LOCAL = {
kdc = dc.lab.local
default_domain = LAB.LOCAL
}
 
[domain_realms]
.LAB.LOCAL=LAB.LOCAL
LAB.LOCAL=LAB.LOCAL

Once you are done simply hit :wq to save and exit.  In order to grant vCO permission to access our newly created krb5 file you will also need to change ownership of the file using the following command

chown vco.vco krb5.conf

And, in order for changes to take affect, restart the vCO service – you can do this from the configuration page->Startup Options or simply

service vcod restart

Whew!  Ok!  Getting somewhere….Now we need to add the host into our configuration of the Powershell plug-in.   I find the easiest way to do this is to simply run the ‘Add a Powershell Host’ workflow however you can develop the script/code on the fly to add the host during your own workflow if you want.   The way I have documented however is as follows…

Browse to the PowerShell plug-in configuration by expanding Library->PowerShell->Configuration in the workflows view of your vCO Client.  Right click ‘Add a PowerShell host’ and select Start Workflow.

vCO-AddHost1

Here we need to add a few key pieces of information.  Enter a name for your PowerShell host – this can be whatever you wish, then enter the HOSTNAME of the host you setup (kerberos will not work with IP)   and click Next.

vCO-AddHost2

The only item that needs to be changed on the Host Type screen is Authentication; be sure Kerberos is selected and click ‘Next’.

vCO-AddHost3

In the User Credentials screen you have a couple of options in regards to Session mode.  Again since this is a lab environment I selected Shared Session, however if you were looking at a more production type deployment you might want to explore the Per User settings which will execute commands under the credentials of the current user connected to vCO.  Enter in some credentials with access to vCO and click ‘Submit’.  The workflow should kick off and you can watch it flow through the different elements.  When done, hopefully you have a nice green check mark beside it!

Now that we have successfully installed the Powershell plug-in and added a Powershell host lets go ahead and create a script on our Powershell host to run in order to make sure everything works.  Although my end goal is to completely configure a host –  for simplicity sake I’ll use a small snippet of the complete script.  So I have placed the following script on my PowerShell host to simply add a new VM Network to vSwith0.  As you can see the script is pretty simple, takes two parameters, a host and a location code.  The location code is used to represent uniquness in my environment and is actually used multiple times in the complete script for the hostname, datastores, etc….

1
2
3
4
5
6
param ($hosttoconfigure, $locationcode)
add-pssnapin VMware.VimAutomation.Core
$username = "Host Username"
$password = "Host Password"
$success = Connect-VIServer $hosttoconfigure -username $username -Password $password
Get-VirtualSwitch -Name vSwitch0 | New-VirtualPortGroup -Name "$locationcode-VM_Network" -confirm:$false

So let’s get started on our workflow to call this script.  Again, create a new workflow and call it what you will.   Once you are in the workflow editor move to the Inputs tab.  Here we will get the information from the user that we require in the script.  So go head and add a couple of inputs to the workflow, one being hosttoconfigure (Type VC.HostSystem) and locationcode (Type String).

vCO-SetupParameters

By selecting our host parameter and clicking the eye icon we can set the ‘Show in Inventory’ presentation property on the host input.  This will basically allow the user to browse through their vCenter to select the host when running the workflows, so might as well go ahead and do that as well.

vCO-PresentationProperty

The Powershell workflow that we will be using is called ‘Invoke and external script’ and requires 3 parameters; One, a Powershell Host which we have setup previously, the second is the script to execute, and the third is the arguments to pass to the script.

vCO-PS-SetupParameters

Once on the Schema tab go head and drag the ‘Invoke an external script’ workflow into yours.   When you see the parameter setup black bar pop up click ‘Setup’ and we can have a look at the parameters.

vCO-PS-PromoteParameters

Through this screen we can basically promote or link the parameters from the Script workflow to our main workflow.  You can see that I’ve done a few things.  One, I’ve set the host parameter to a value (same as creating an attribute) and browsed through my inventory to select my Powershell host that we created previously.  Secondly I manually inputted the path to my Powershell script in the externalScript parameter.  Thirdly I selected to skip the arguments parameter at this time.  I’ve done this because I need to pass the hostname as well as the locationcode parameter from my main workflow to this parameter which we will do with a separate element called a Scriptable task.  Go ahead and click ‘Promote’.

vCO-PS-ScriptableTask

So now we have our main input parameters setup (locationcode and hosttoconfigure) as well as our script setup and ready to go.  We just need to tackle that arguments parameter.  As I said we will do this with a separate Scriptable Task workflow so go ahead and drag that into your schema, just before your Invoke External Script.   A scriptable task is just that, kind of a blank canvas to do any sort of scripting (javascript) that you desire.

vCO-PS-ScriptableTask-SetupInVars

So let’s go ahead and click the pencil icon to edit our scriptable task.  There are few IN parameters that we are going to need inside of our script; The first is hosttoconfigure and the second is locationcode.

vCO-PS-ScriptableTask-SetupOutVars

Now move on to the OUT parameters.  We will need to create a new out parameter to store our arguments, so click the link for a new parameter and create a new workflow attribute called scriptArgs of type string.

Now we need to move to the Scripting tab.  This is where we can concatenate a property of the hosttoconfigure parameter and the locationcode to populate our newly created scriptArgs variable.  Honestly it’s a one-liner.  I’m sure there is a way to create this workflow without even requiring this whole Scriptable task but this is the way I got to to work (again, my FIRST vCO workflow).  Copy/Paste the following into your scripting tab.

scriptArgs = hosttoconfigure.Name + " " + locationcode;

Ok, you can close out of your Scriptable task workflow now.  We are almost there.  All that we have left to do is map the External Script workflow paramater arguments to our Scriptable task elements parameter scriptArgs.  Thankfully this is an easy thing to do.

vCO-PS-MapVars

Once again go into your External Script element and click on the Visual Binding tab.  Here, as shown above, we simply need to drag the scriptArgs in attribute over to the arguments in parameter.

vCO-PS-AllDONE

Guess what!  Your done!  If everything has been setup properly and I’ve done a good job at explaining what to do then you should be able to Save and Close your workflow and actually run it on a host (a test host of course).  The result – you should get a VM Network setup on vSwitch0 – oh and a pretty green checkmark beside your workflow 🙂

At this point I’m going to cut off this post since it’s getting pretty long.  That being said I’m not going to end the series!  I’m always looking at ways to better automate things and you know, having users type in that location code just isn’t good enough for me, a lot of room for error there; they could type it in wrong, do the same location twice, on and on and on…  And hey, I have a database already setup with my location codes in it and whether or not they have already been deployed.  So, stay tuned for Part 5 of my series where we will go through configuring the SQL plug-in and setting up our location input parameter to be populated by an SQL table – as well as update that same table on completion of our script.

My first vCenter Orchestrator Workflow

Friday Shorts – Simplivity, Veeam and vOpenData

Too bad, she said she doesn’t want you here when she gets back because you’ve been ruining everybody’s lives and eating all our steak. – Napolean Dynamite

SimpliVity out of stealth

simplivityOne of my fellow #vDB comrades Gabriel Chapman ( blog / twitter ) has joined SimpliVity.  I’ve not heard of SimpliVity before Gabe joined them but since have done a little reading on their product offering.  In a nutshell they provide a simplified building block solution for your virtual environment, one that contains everything you need to get going (storage, compute, network) in a 2U format called the OmniCube which is built for a scale-out environment.  The box looks pretty slick in the fact that it contains built in deduplication, replication, ha, etc…  If you have some time I would definitely consider going and checking them out over on SimpliVity.com – also vExpert Chris Wahl has a great post on their product over on his blog.  Congrats Gabe on the move – looks like a good one!

Veeam v7 to backup to tape!

veeamlogoTape is dead right – apparently not, Veeam has announced their support of adding an archive to tape option into version 7 of Backup and Replication.  Now I’ve been long off tape, but I’m sure this is appealing to those that are not.  Honestly it does make a good case for Veeam in the case that companies require retention for auditing.  This is the 5th peek into what Veeam is bundling with v7, along with vCloud Director support, a new vSphere Web Client plug-in, Veeam Explorer for SharePoint and a virtual lab for Hyper-V.  Be sure to sign up on their site to get notified of the v7 features as they announce them.

Have you seen/contributed to vOpenData?

vopendataAn interesting community project has been ramping up over the last couple of weeks called vOpenData.  Basically Ben Thomas and William Lam have created a database that compiles data taken from YOUR virtual infrastructure, applies some analytic s in the back end and pops out a pretty sexy page showing a ton of statistics showing things like average vmdk size, average number of datastores per cluster, etc…  If you have a few minutes check it out and if your up to it, contribute!

Get your hands on a free Unitrends NFR lisense – and some top notch community knowledge to boot

unitrendsI’ve just been informed that Unitrends, one of the great sponsors of this blog will be hosting a webinar with none other than the great Eric Siebert!  You know, the vExpert, Author, Blogger – oh and the guy behind the coveted vSphere-Land Top Virtualization Blogs – yah, him!

Eric and Unitrends will be going over how you can utilize blogging tech experts and peers writing from the IT trenches as well as the following points…

  • How the virtualization blogger community has evolved
  • Why you should pay attention to what bloggers are saying
  • Top virtualization blogs to watch in 2013

This is certainly one that I don’t want to miss!  It’s always great to hear Eric speak about the state of the blogosphere!  He certainly has been through mostly all of the blogs out there during his yearly vote!  So, if you have nothing to do on April 18th around lunchtime (12PM EST) why not go and sign up to watch this – landing page is here.

Oh, did I mention that Unitrends is giving EVERY attendee a free NFR license of their Unitrends Enterprise Backup – not too shabby for just showing up.  Also, one of the lucky attendees could get their hands on a $200 ThinkGeek.com giftcard!

See yah there 🙂

My First vCenter Orchestrator Workflow – Part 3 – Create a test workflow and see the awesomesauce

imgOrchestrateOk we are finally getting somewhere now with this series! So far we have downloaded, installed, and configured our vCO appliance. As well, we have registered our vCO instance with both vCenter and our SSO instance. This post will take us through verifying and testing our installation by creating and setting up a small workflow that we can then assign to some inventory objects inside of vCenter. This will allow us to perform that right-click magic in the Web Client and see for ourselves some of the awesome integration vCO and vCenter have.

vCOClient

With that said let’s get started on our test workflow. To do so you will need one of clients available to vCO. As you can see in the screenshot vCO provides you with a couple of options to start the client; one simply runs a java applet and the other let’s you install a client directly on your machine – whichever method you chose you end up sitting at the exact same login screen. Once you get there you should be able to simply input your vCO IP as the Host name and your proper credentials.

OK! So here we are, the vCO workflow development interface. Look a little foreign to you? No worries, it did to me as well. Actually, it still kind of does, this is just “My First” vCO workflow remember! So for the most part I’ve only really explored the workflow icon (shown below).  The others are simply Home (home), Scheduler (Allows scheduling of workflows), Policies ( Allows other plugins to trigger the kick off of workflows), and Inventory (You will see your vCenter inventory objects here). For now, we need the Workflows section active.vCOWorkflowWorkspace

vCONewFolder

So after you expand the Library tree you should see several folders by default. These folders contain all of the workflows that vCO is aware of. Obviously we can add more by creating our own or installing plug-ins (covered in Part 4). For now we will just create one of our own workflows. Before going to crazy I always like to create my own folder for things like this. I get a bit nit-picky about file management sometimes 🙂 To do so is pretty simple – Right Click Library -> Add New Folder and give it a name!

vCOWorkflowEditor

 

So now it’s time to create our workflow – Again Right-Click the folder you want to store it in and Select New Workflow and name it. At this point a new window, the workflow editor will open up. There is a lot of information and tabs here and to be honest I’m not going to explain what they all are. Partly because it would make this post much too long, but mostly because I don’t have a grasp on what they all are :). The main tab that we will be working in is called Schema. This is where we setup all of the flow elements inside our workflow. Once there you will see our main window is displaying the flow of everything, and the left hand side is showing all of the workflows that we can add to our workflow. The one I am interested in is ‘Reboot host’ As you can see you can browse through the tree of All Workflows to get to it or you can simply use the filter box at the top to search for specific workflows. Once you find it you simply add it to your workflow by dragging it into your flow window.

vCOInputsCurrentWorkflow

vCOPromoteInputsAfter doing so you will see a black bar along the top of the screen asking about the activities parameters. Something to know – workflows have inputs and outputs – these are pretty self explanatory. When we created the workflow initially it had inputs and output, and then when we dragged the Reboot Host workflow into ours it also had inputs and outputs. So what this is asking is if we would like to move the Reboot Hosts inputs into our workflows inputs. In this case this is something we want to do. So go ahead and click ‘Setup’. Now we see our ‘Promote Workflow Input Parameters’ window. This will allow us to do a few different things; First of all, we can promote or move our inputs from the reboot host workflow to our workflow, and secondly we can decide to assign default values to them at the same time. As you can see, the ‘Reboot Host’ workflow takes two inputs; one being the host and the other being the force switch. Leave host as it is but if you want you can set a default value of ‘Yes’ to force by selecting the value option and then the yes option. Then click ‘Promote’.

If you look at your Inputs section now you will see that only host is listed. This is because we require the user to tell us or select the host we wish to reboot. But wait, what about force?!?! Well, by assigning a default value to this input parameter we have actually converted this to an attributes. Attributes are available on the General tab. Anyways – this workflow is now complete! Go ahead and select ‘Save and Close’. You will notice that vCO will also handle a bit of version history for us! Awesome stuff!

Alright! We are done with vCO for now. Let’s flip back to our web client and assign this workflow to be executed on certain objects. Navigate through the web client to the vCenter Orchestrator section, then Select vCO Home and look in the Manage tab. This is where we will add our newly created workflow to our right-click context menu when associated with host. Click the + sign to add a new workflow. In the Available workflows browse through the tree until you find your workflow and click ‘Add’, then select the inventory objects to run it on – in our case, just a host and click ‘OK’

vCOAddWorkflow

So, after all of this we are now ready for the awesomesauce! Get back into your Hosts and Clusters view and right-click on a host. Once the ‘All vCenter Orchestrator Actions’ menu loads have a look at what you see! Reboot Craziness!!! Your workflow!! If you see fit, go ahead and select it to kick off the workflow. You may be prompted for a token delegation – if so go ahead and click ‘Approve’ – I have no idea what this is 🙂 When your workflow window opens you can see that your host has already been pre-populated with our right-click. You can click Finish to start the workflow immediately or Next to setup a schedule of sorts. ***Warning – this will reboot your host *** – don’t know if that’s needed but whatever 🙂

vCOItsthere

So there you go! We’ve successfully created a test workflow in which we integrated into and executed from the vSphere Web Client. Pretty awesome stuff! I hope you are starting to see some of the benefits of vCO now! Next we will get back on track with our workflow and dig a bit deeper into creating workflows by installing the Powershell plugin and getting vCO to execute a script for us!

My first vCenter Orchestrator Workflow

My first vCenter Orchestrator Workflow – Part 2 – Installing vCenter Orchestrator

orchestrate2Welcome to the second part of My first vCenter Orchestrator Workflow series.  Now before we can really get into the functionality of vCenter Orchestrator we obviously need to go through the task of getting vCO installed and configured. VMware has provided a couple of different ways to do this; one being installing on a Windows box, normally on the same server as your vCenter Server. And the second being through the download of a virtual appliance. For the sake of this series I will go over the installation and configuration of the appliance as it seems to be the trickier of the two.  If you go with the windows installation it is simply included as an installable package on the vCenter Server media.

So first off you need to go and download the vCO appliance through your myvmware account.   vCO is bundled in with vCenter Server so if you have a copy of vCenter you are good to go with vCO (I think foundation only comes with the ability to run workflows and not edit)   From here you simply need to import the ovf appliance into your environment using the typical  File -> Deploy OVF Template and power it on.

appliance-installed
Once the appliance has fully booted you will notice that it displays a slew of URLs and information.  Don’t worry!  By simply pointing your browser to the IP address of your vCO server you will see the same list – you don’t need to remember all of the ports.   There are a couple we need to pay close attention to here; Orchestrator Configuration (used to perform Orchestrater setup, plugins, ssl certs, etc – this is the main ui you will work in) and Appliance Configuration (the setup pages to manage your actual appliance settings, such as networking, ntp, admin passwords, etc.. )

For your documentation (more so mine) I’m going to list the default usernames and passwords for vCO below as it can be tricky trying to find some of them in the documentation.

Orchestrator Configuration – vmware/vmware – will prompt for new password when you first login
Appliance configuration – root/vmware – change password manually in the ‘Admin’ section.

So to get started let’s browse to Appliance Configuration – As described above here is where you can perform appliance related tasks such as setting up ntp, networking and change your root password. If you have used any VMware virtual appliances before you should be somewhat familiar with this interface.

appliance-configuration

Same look and feel as most VMware Virtual Appliances

Once you have your network settings configured we can continue on to the Orchestrator Configuration. This is the main interface for configuring all things Orchestrator. We have quite a bit of work to do here so lets get started. After logging in with the default credentials (vmware/vmware) you will be prompted to change the password so go ahead and do so.  Now we need to setup our Orchestrator appliance to listen on the proper IP address which set in the appliance configuration as well as work with the new SSO service that was shipped with vSphere 5.1. To do this we will first stop the Orchestrator server service. This can be done through the ‘Startup Options’ section on the left hand menu, then clicking ‘Stop Service’.

orchestrator-networking

Networking

For the network listener, simply select the ‘Network’ menu on the left hand side, then select your IP Address in the associated dropdown box, then click ‘Apply Changes’ Easy peasy so far – well, now we are about to explore SSO and SSL Certificates – yikes!

In the same section (network) select the SSL Trust Manager tab. Here is where we list all of our imported ssl certificates. In order for SSO to work we need import a couple certs; one from our vCenter Server and the other from our SSO service. To do this there are a couple of URLs we need to know.

First enter in the following URL (https://IP_of_vCenter:443/ and click the import button. The certificate should be displayed in your browser. Simply click ‘Import’ once again to pull it into vCO.

Importing SSL Certificates

Importing SSL Certificates

Next we need to repeat the exact same steps excepting using https://IP_of_vCenter:7444/ as the URL.

Now that we have the required certificates we need to setup Orchestrator to point to SSO for authentication purposes which is done by, you guessed it, the Authentication section. Switch your authentication mode dropdown from LDAP Authentication (default) to SSO Authentication. Then you need to input your SSO Host – This will be the same as your vCenter unless you have explicitly installed SSO elsewhere in your environment. Also we need an admin username and password on your SSO host. Remember a way back when when you installed SSO and it was prompting you for admin usernames/passwords – I hope you remember these because we need them now. By default if you didn’t make to many changes your username might be [email protected] – unfortunately I can’t help you with your password 🙂 Once done select ‘Register Orchestrator’.

vCO will authenticate users using the SSO installation included in vSphere 5.1

vCO will authenticate users using the SSO installation included in vSphere 5.1

On the next page you can actually put more restrictions on who can and can’t be a vCO administrator. I left all defaults here and simply clicked ‘Accept Orchestrator Configuration’.  Basically you are configuring what users or groups can be vCO admins.

Alright, almost there – Now let’s go ahead and get the vCenter Server plugin installed and activated – we will go a little more in depth with plugins later so I’ll leave most of the details out that this point.  Simply select your Plug-ins menu and enter in a username and password in the boxes provided (SSO should be working now), select the checkbox next to the vCenter Plug-in and click ‘Apply Changes’ .

Installing the vCenter Plug-in

Installing the vCenter Plug-in

This might be a good time to give your vCO server a nice clean reboot or at least restart the services under Startup Options.  As you can see there are a few plug-ins stating they will perform the installation at the next server setup.  Either way you should see a vCenter Server menu option appear, once it’s there select it, then go to the ‘New vCenter Server Host’ tab. Fill in all of the information in regards to your vCenter Server

Adding a vCenter Server

Adding a vCenter Server

As you can see most the options here are pretty basic with the exception of the user strategies.  Basically ‘Share a unique session’ will result in orchestrator creating only one connection back to your vCenter Server.  This will certainly use less resources and may be ‘secure-enough’ for some small deployments.  The ‘Session per user’ option will actually execute the workflows under the user credentials of the user that is logged into Orchestrator.  This does have the ability to use a few more resources however provides a bit more secure and audit-able environment.  I used the ‘Share a unique’ session as I’m just running through my lab at this point.

OK, i told you we had a lot of work to do in here – but for the most part we have things configured now. If you want to double check you can log in to your vSphere Web Client, Select the vCenter Orchestrator item on the left hand navigation menu and you should be able to drill down and see your new vCO server registered.  If not and you have followed all these instructions to a tee with no break, you may want to give your vCO server a reboot and have a look. It should be there  🙂

vCO registered within the vSphere Web Client

vCO registered within the vSphere Web Client

At this point you can give yourself a huge pat on the back.  You’ve now succesfully setup and configured the vCO virtual appliance and have registered it within your vCenter Server.  In the next portion of this series I will discuss how to create a small test/sample workflow in order to test our integration between vCenter Orchestrator and the vSphere Web Client.

My first vCenter Orchestrator Workflow

My first vCenter Orchestrator Worlkflow – Part 1 – Introduction

Orchestrate all of the thingsvCenter Orchestrator in it’s basics is a workflow development tool that can be used to schedule and automate multiple tasks in your environment.  A tool that can be used to create and execute workflows not only on your vSphere environment, but with the use of plugins you can manage other types of applications such as Active Directory, SQL, etc.  In the past I’ve often heard of vCO being described as a hidden gem inside of your vCenter Server; meaning it’s usually already there and licensed  but for the most part, you are probably not using it.  Such is the case with myself. I’ve often thought about trying to learn this technology in order to execute some of my common day to day tasks through a more automated and scripted fashion but I’ve always resulted to things like PowerShell and PowerCLI to do the same job.  Why?  Well, comfort really.  I already have a good handle on Powershell technology and could get things done faster there rather than learning something new.  That being said with the introduction of vSphere 5.1 a bunch of new features and enhancements were made with the vCenter/vCO interoperability.  The biggest IMO was the ability to execute a vCO workflow while directly inside of the vSphere Web Client – contextually!!!  This integration is what enticed to have a closer look at vCO.  Basically I now have the ability to create workflows that can do pretty much anything and grant access to myself or to others to simply right-click a host from within vSphere and execute them.

contextualThus leads me to these series of posts where I will try and take you though my experiences with vCenter Orchestrator; and it couldn’t come at a more opportune time.  I have approx 50 hosts to configure and deploy within the next few months and in effort to keep them consistent I decided to do so with a PowerCLI script that I had written a while back.  The only difference being I will be executing this script through vCenter Orchestrator (to get that super awesome right-click functionality).  Now there is certainly some overlap here.  A lot of the actions that the PowerCLI script performs actually have workflows already created in vCO that do the same thing however in this case I’ve decided not to use them – baby steps right!  Also, it helps to highlight the power of the vCO plugins – I can in fact do things like execute PowerShell commands, run queries against SQL servers, move objects around in Active Directory, etc.

So with that said I guess you could call this post an introduction of sorts with nothing too technical included.  Be sure to check out Part 2 – Installing and configuring vCenter Orchestrator where we will dive a bit deeper into the setup of vCO.

My first vCenter Orchestrator Workflow

vCenter Operations Manager now sits at 5.7

VMware LogoIt should be no surprise to any of my regular readers or followers that I am a huge fan of vCenter Operations.  Being a VMware customer I find that it is a huge time-saver when trying to pin point performance issues within our environment, as well as giving us a great first step in trying to do capacity planning and figure out where we are going to need to go next.  So, it should also be no surprise that I get just a little excited when there is a new release of the product; be it only a .1 release, still super awesome none the less.

It goes without saying that you should see a few posts diving deeper into some of the new features listed below as well as in the official release notes, as well as a quckie about how to upgrade, but for now, without further ado, the newest features from vCenter Operations 5.7 from vmware.com…

More Flexibility with Capacity Planning

  • Assess capacity risk and plan by allocation and/or actual demand: Set policies based on your varying business needs to assess capacity risk, efficiency, and forecast. For example, different buffers, over-commit ratios, alert thresholds, business hours, etc., across production and test-dev environments.
  • New views for Cluster Capacity Risk: Quickly identify via color-coded Cluster capacity risk view which clusters grouped by business criteria, etc., are at capacity risk—facing a capacity shortfall now or in the near future or just not sized right. Drill down for each cluster in the Cluster Risk Detail view to analyze which resource is it constrained on and why.
  • New policies for common environments and workloads: New out-of-the-box policies, such as Production and Test-Dev policies, enable quick set-up of vCenter Operations Manager capacity settings for common types of environments. Additional new out-of-the-box policies, such as Batch workload, Interactive workload, and Ignore VMs policies, help fine-tune capacity configuration settings to accurately right size and analyze different workloads based on their performance characteristics.

Improved Self-Monitoring

This release introduces new diagnostics metrics to monitor the health and availability of vCenter Operations Manager components, such as Analytics, Collector, Active MQ, Web server, database, and operating system.

Widgets with Improved Flexibility and Usability

  • Health Tree Widget: Easy visualization for large number of objects.
  • Generic Scoreboard Widget: Support for Sparkline, string metrics, and metrics filtering by resource.
  • Metric Sparkline Widget: Configurable color ranges and units, support for resource type and label.
  • Resource Widget: Customizable to add metrics beyond health.
  • Top-N Analysis Widget: Support for analysis based on latest values.

New Custom Relationship Widget

Allows you to build a custom resource hierarchy and relationship view, just like the existing out-of-the-box vCenter Server view.

Custom UI Import and Export Changes for Dashboards and Super Metrics

  • Export format changed from binary (.bin) to XML (.xml): .bin formats are still supported for backward compatibility.
  • DBCLI Enhancements: Programmatically import and export Super Metrics.
  • Pre-population of Dashboard objects during import.

Balanced Metrics Profile

This release introduces a new metrics profile that reports a reduced set of metrics. Increase the scalability of vCenter Operations Manager to support more resources by changing the metrics profile to the new “Balanced” profile in vCenter Operations Manager Administration.

VMware vCenter Infrastructure Navigator Filtering Capability

You can configure how resources discovered by vCenter Infrastructure Navigator are displayed in vCenter Operations Manager. This release introduces a configurable filtering capability to the vCenter Infrastructure Navigator adapter to control Application service and Application resource reporting. For each resource type, you can configure either “blackList” or “whiteList” filtering in the configuration file filterList.txt.

  • blackList: The vCenter Infrastructure Navigator adapter ignores specified entries. If an Application Service name or an Application name is included in the “blackList,” it is not reported by the vCenter Infrastructure Navigator adapter. This is the default setting. The vCenter Infrastructure Navigator adapter filters unknown Application service names by default.
  • whiteList: The vCenter Infrastructure Navigator adapter reports only the specified entries. If there are no entries added to the whiteList mode, none of the resources of the corresponding resource type are displayed.

 New Browser Support

This release adds new support for the following browsers: Apple Safari version 6, Google Chrome versions 24 and 25, and Mozilla Firefox 18 and 19.

Security Hardening

This release includes additional security hardening and increases compliance with The Defense Information Systems Agency (DISA) and The Security Technical Implementation Guides (STIG) guidelines.

 Go and download a fully featured 60 day trial for yourself here.

Have a great time at VMworld on Veeam’s dime!

veeam_logoOnce again the folks over at Veeam software are giving away a free full conference pass to VMworld – Barcelona or San Fran.  VMworld is the must go to conference for any virtualization professional, so if you want to go but can’t get your employer to shell out the $$$ to go, be sure to enter into Veeams’ monthly drawing – you may just end up being the lucky one who wins…

And if you don’t win, ah well, you will stay entered into future monthly drawings which aren’t to bad themselves – I’ve seen these guys giving away iPads, Surface Tablets, TechEd Passes – no reason not to enter really…

Good luck – and I hope to see you there…