First the apology =) Unfortunately I wrote way too many cmdlets recently for vCD, so I really don’t have enough chapters or cycles to get into the details around each cmdlet.  I tried to include examples and descriptions for the cmdlets, but didn’t quite make it through all of them.  It should be very self explanatory when looking at the name and the run-time example.

The goal of the cmdlets was to build the framework necessary to complete a whole bunch of automation with vCD, satisfying a primary use case for labs (actual lab cmdlets not here).

There is a lot of pretty cool stuff in here, some of the highlights are as follows.

Network

There are a handful of network related cmdlets.  An important one for any VApp deployment is to be able to specify the External Network correctly (Update-CIVAppParentNetwork).  In addition when a VApp is deployed you probably want to see the accessible remote IP (Get-CIRouterInfo).  A new twist on the VApp networking has to do with the fencing that can take place.  There is a cmdlet to view the fencing information (Get-CIFencing) for CIVMs to show their inside and outside mac addresses.  Another useful one is (Get-CIVAppNetworkingFirewallRules) which displays the firewall rules associated to a VApp.

Disk

One of the great things about vCD is the use of thin and linked clones (fast provisioning).  However, the reporting on a per object basis isn’t quite there.  For this we leverage the Get-CIVCVM to cross-link the CIVMs to their respective VC VM’s to get details per virtual disk (Get-CIVAppDiskGroupings, Get-CIVAppDiskUsage).  This is all fine and great, but I wanted to take a step even further than this and describe the relationship among VMs in the fast provisioning world (Get-CIVMDiskFileChain,Get-CIVMDiskFiles).  These commands will list out the relevant virtual disks and show the amount of VM’s sharing those virtual disks and the chain length.

VApp/VAppTemplates and Catalogs

Note that due to the complexity of deployment the Instantiate-VApp cmdlet has been changed.  In a previous post I demonstrated how you might be able to specify all of the relevant details (NAT, Firewall, etc) on the fly.  This however is a bit tough to get going correctly and for most not necessary.  So instead I opted to go for the “Clone” route which takes an existing configuration contained in a VAppTemplate and duplicates as much of it as possible versus specifying these things manually.  I have also included another goodie (DeployLab-FromOrgCatalogToAnotherOrgCatalog) which demonstrates the VC to VC scalability of vCD without using the OVF export routine (future post to explain).  Another good one is the ability to add VApps to catalogs and duplicate VAppTemplates among catalogs (Add-CIVAppTemplateToCatalog).  Last but not least, in order to leverage VC to VC transfers correctly we have included the ability to consolidate VAppTemplates in the catalog (Consolidate-CIVAppTemplate).  A new concept for vCD are shadow VMs.  These are used to track back to original VApp Templates and can be difficult to track down at times so there is a cmdlet for this as well (Get-CIVMShadow).

WARNING: The VApp/VAppTemplate cmdlets allow you to do things that might bring you outside of your “workspace” which could cause OVF related activities (not good for most cases, lose VM identities, etc).  Watch VC to see what is happening during these processes to ensure this is not the case.

VC Related

When running large scale environments there are always key things that need to be aligned.  I created a couple of easy ones (Get-VMHostDateTime and Get-VMHostSoftwareList) to help out with ensuring the hosts are aligned from a time perspective, and verifying all hosts were running the same vcloud agent version.  You will notice that there are a handful of cmdlets that leverage a VC connection (Connect-VIServer) in order to work correctly.  These are where I lookup the underlying VI information for an object to give a more complete view of something.  These hybrid views have turned out to be very powerful.

Anyways, have fun with the 43 cmdlets!  The following is unsupported and probably soon to be replaced =)

• Install PowerCLI 5.0.1, with Cloud
• Download the Cmdlet module here.
• Import-Module .\custom_vcd_cmdlets.psm1
• Connect-CIServer
• Connect-VIServer on some cmdlets

Remove-Catalog

Get-Catalog -name Catalog01 -org myOrg | Remove-Catalog -Confirm:$False

New-Catalog

New-Catalog -name Catalog01 -Org myOrg -isPublished:$true

Remove-CICustomProperties

Get-CIVApp Google* | Get-CIVM name | Remove-CICustomProperties

Get-CIDatastore

Get-ProviderVdc Google* | Get-CIDatastore

Get-CIMetadata

Get-CIVApp Google* | Get-CIMetadata

New-CIMetadata

Get-CIVApp Google* | Set-CIMetadata -key "test" -value "testvalue"

Remove-CIMetadata

Get-CIVApp Google* | where{$_.key -eq "test"} | Remove-CIMetadata

Update-CIMetadata

Get-CIVApp Google* | where{$_.key -eq "test"} | Update-CIMetadata -value "updated"

Get-CIRouterInfo

Get-CIVApp Google* | Get-CIRouterInfo

Update-CIUser

Get-CIUser labsorg | Update-CIUser -description 1

Remove-CIVApp

Get-Org Labs | Get-CIVApp Base-ePod-Basic-v8 | Remove-CIVApp

Start-CIVApp

Get-CIVApp Google* | Start-CIVApp

Get-CIVAppDiskGroupings

Get-CIVApp VApptest* | Get-CIVAppDiskGroupings

Get-CIVAppDiskUsage

Get-CIVApp test* | Get-CIVAppDiskUsage

Update-CIVAppParentNetwork

Get-CIVApp Google* | Update-CIVAppParentNetwork -parentnetwork (Get-Org (Get-OrgVdc ovdc_labs_c03).org | Get-OrgNetwork orgnetwork_external01_c03)

Get-CIVAppResourceUsage

Get-CIVApp test* | Get-CIVAppResourceUsage

Consolidate-CIVAppTemplate

Get-CIVAppTemplate Base-ePod-Basic-v8 -Catalog (Get-Org HOLDEV | Get-Catalog HOL_BASE_CAT01) | Consolidate-CIVAppTemplate

Remove-CIVAppTemplate

Get-CIVAppTemplate Base-ePod-Basic-v8 -Catalog (Get-Org HOLDEV | Get-Catalog HOL_BASE_CAT01) | Remove-CIVAppTemplate

Update-CIUser

Get-CIUser labsorg | Update-CIUser -description 1

Get-CIVAppTemplateDiskUsage

Get-CIVAppTemplate test* | Get-CIVAppTemplateDiskUsage

Get-CIVAppTemplateResourceUsage

Get-CIVAppTemplate test* | Get-CIVAppTemplateResourceUsage

Add-CIVAppTemplateToCatalog

Get-CIVAppTemplate Google* | Add-CIVAppTemplateToCatalog -VAppTemplateName test1 -Catalog (Get-Org labs | Get-Catalog test) -ToOrgVdc (Get-OrgVdc test)

Get-CIVAppTemplateTotalUsage

Get-CIVAppTemplate test* | Get-CIVAppTemplateTotalUsage

Get-CIVAppTemplateVM

Get-CIVAppTemplate Google* | Get-CIVAppTempalteVM

Add-CIVAppToCatalog

Get-CIVApp Google* | Add-CIVAppToCatalog -VAppTemplateName test13 -Catalog (Get-Org labs | Get-Catalog test) -OrgVdc (Get-OrgVdc OvDC_LABS_C03)

Get-CIVAppNetworkingFirewallRules

Get-CIVApp Base-ePod-Basic-v8 | Get-CIVAppNetworkingFirewallRules

Get-CIVAppTotalUsage

Get-CIVApp test* | Get-CIVAppTotalUsage

Get-CIVCVM

Get-CIVM test* | Get-CIVCVM | Get-VMDiskFiles

Get-CIVMDiskFileChain

Get-CIVM "vpodrouter v3" | Get-CIVMDiskFileChain

Get-CIVMFencing

Get-CIVApp | Get-CIVM | Get-CIVMFencing

Get-CIVMHardDisk

Get-ProviderVdc Google* | Get-CIDatastore

Get-CIVMShadow

Get-CIVMShadow

DeployLab-FromOrgCatalogToAnotherOrgCatalog

Get-CIVAppTemplate HOL12-HyperV-SPwithAvamar-v9-Clint -Catalog (Get-Catalog HOLDEV_HOL12_CAT01) | DeployLab-FromOrgCatalogToAnotherOrgCatalog -ToOrgVdc @("OvDC_LABS_C01","OvDC_LABS_C02","OvDC_LABS_C03","OvDC_LABS_C04") -ToOrgVdcMC OvDC_HOLDEV_HOL12_C01_MC01 -prefix "MC_" -fromCatalog "HOLDEV_HOL12_CAT01" -ToOrg "Labs" -verbose

New-Org

New-Org -Name name -FullName fullname -Enabled:$true -PublishCatalogs:$true

New-OrgGroup

New-OrgGroup -Name name -GroupName GroupName -RoleName RoleName

Set-OrgLDAP

Set-OrgLDAP -name  orgName –orgLDAPSystem:$true

New-OrgVdc2

New-OrgVdc2 –name fromOrg –FromOrgVdcName fromOrgVdc –orgVdcName newOrgVdc

Instantiate-VApp

Instantiate-VApp -name "test" -catalogname HOLDEV_HOL22_CAT01 -VAppTemplateName HOL22-Test-v1 -orgvdcname OvDC_HOLDEV_HOL22_C01 -mode Clone -poweron:$false -deploy:$false

Get-VMDiskFiles

Get-CIVM test* | Get-CIVCVM | Get-VMDiskFiles

Get-VMDiskUsage

Get-CIVM test* | Get-CIVCVM | Get-VMDiskUsage

Get-VMHostSoftware List

Get-VMHost | Get-VMHostSoftwareList | where {$_.name -match "vcloud"}

Get-VMHostDateTime

Get-VMHost -server vc01 | Get-VMHostDateTime

It is very important to mention that this configuration is done using the custom portal and NOT the vSphere portal in vCOps.  The vSphere portal is statically configured in a way that allows you to get very useful data and switch contexts for that data in an out-of-the-box way.  The custom portal is where you can go (Enterprise/+ only in v1+v5) and create your own complete dashboards.  The custom portal is also the location where you access the 3rd party metrics that may have been brought in through 3rd party adapters (Java RMI) or the vCOps open adapter (HTTP Post).

Requirements

• vCOps Enterprise
• https://vcops/vcops-custom/

New Dashboard

The first thing that I want to do is walk through how to create a new dashboard. There are default templates that come with vCOps which are those that include a set of configured/unconfigured widgets. We could leverage these templates since they contain widgets and dimensional styles that may be desired, or we could use the template and remove the widgets once they get added. Instead of either of these  approaches, I will demonstrate how to create a dashboard from individual widgets without a template.

Login to vCOps through the custom URL as listed above and press the “+” button on the dashboard row.

You will see the template screen load, go ahead and press the icon in the top left corner as shown below. This will bring up the screen that allows us to simply choose widgets.

Now we get to choose the style and name of the widget that we are creating. On the left side you can see the drop down where we decide how many columns that will be presented in this vCOps dashboard.

We have selected three columns and you can see on the right side that our page setup has changed to three vertical columns. Our next option is to actually slide the two columns in the middle left and right which creates custom dimensions for the width of my widgets.

In the following screenshot we are now showing the list of available widgets on the left and the subscribed widgets for this dashboard on the right. I can simply drag and drop any widget from the left to the right. The order does not matter on the right side and has no permanent effect of how widgets will be displayed on the dashboard, so simply drag and drop any widget that you would like.

I have dragged over a handful of widgets that I will now demonstrate how to configure. You can see the health-workload widget, generic scoreboard, heat maps, and a metric graph. This by no means indicates the usefulness of any of the widgets, they all have value and I encourage you to play and test them out!

Gadgets with VNX Data – Performance Metrics

This section will demonstrate some of the common ways that you can visualize important VNX storage array information with the scoreboard, heatmap, metric graph widget. We showed you how to create a dashboard above, go ahead and drag the widgets listed to a new dashboard. Once you  have done this click the configuration button from the Generic Scoreboard.

You will notice that the following widget configuration window arises. The information here should be pretty self explanatory. However, I wanted to take a quick second to describe some of the buttons on the interface that are common to vCOps.

The following shows up under the configuration of the widget. On the bottom left of the red box it has an icon marked with an “x”. This icon refers to “clear selections” and removes any rows that you may have selected in the list. This is important to remember as vCOps is filled with selectable boxes and filters. It can be very easy to not get the results that you were expecting because you have an existing selection that may be hidden from you. The button to the right with the green arrow has to do with multiple selects. In this case we are selecting a resource and on the right side vCOps, it is populating metrics for this object. What if we had a case where we had multiple objects (SPA & SP B) which are the same Resource Kind with the same metrics. Wouldn’t it be easier just to select both SP’s and then have the common metrics be displayed on the right? And then when I select a metric and hit the multi-select above those metrics that both SP’s metrics populate in the list at the bottom? This is exactly how it works.

Ok, time to move on. The following window shows the configuration of the Scoreboard widget. We have populated metrics into the selected metrics box as described. We have also assigned “Box Labels” and “Measurement Units”. You can see from the screenshot below the widget configuration where we display the widget itself that those items show up above the metric and to the right of the metric. The other important thing has to do with the range.

Note: See the User’s Guide (v1.0.2) for more examples and detailed information here.

The range is a tough one to get correct without an example. The “green range” refers to anything up to the green maximum, so in our case we enter “40” for SP utilization. The “yellow range” refers to an amount between the minimum and maximum of that range, so for this we enter “40-60”. We repeat the same in orange as a range of “60-80”. The “red range” is then configured with the minimum of that range, in this case “80” which covers anything between 80 and up. We also configure throughput as IO/s in the scoreboard, but feel free to choose any metric.

The next examples will be leveraging the “Heat Maps” widget. We will be repeating the usage of this widget across many different types of objects, so the explanation of how to configure it in general will only be done once.

The heatmap is an awesome way to visualize data. When looking at the widget generated, there are two main options for displaying metrics. The first is the “Size By” and the second is “Color By”. This allows us to specify two separate metrics for a single resource. The heatmap is used in the Analysis -> VC Analysis tab where VMware has packed in some great generic views. You can refer there for other examples of how you might format information. In terms of storage I would point you to the heatmaps that refer to Datastore, there are some really good ones there.

Getting back to visualizing the data. The heatmap allows us size the boxes displayed by a quantity and color them possibly by a health indicator. For example, if I want to see the hot datastores then I can create a heatmap that looks at the IOs as the size of the box and the response time for that datastore as the color. This is a very powerful view of exactly how my storage is performing out of the box for vCOps. You can even take this to a more VM specific heatmap where you see virtual disk IO and response times. The other bonus for heatmaps has to do with how we group the information being presented. It would be one thing just to show say VMs on a heatmap and size as discussed. It is another thing to actually group those VMs into possibly the ESX host first, and then display the VMs after that. This way we would have another metric displayed which would be the ESX host’s aggregate IO being generated for those VMs along with the previous view of simply VMs.

We leverage this grouping in many different cases. For the examples below we are actually pulling data from 5 different VNX’s. In order to properly segregate out the resources we needed to create a “tier” ahead of time where we could properly define what those resources were. Unfortunately, identifiers (uniqueness of resources) aren’t possible to group by. So we use tiers instead and this generates what you see in the widget screenshot below the configuration where you see the array name itself, and the objects inside of the major group box pertaining to that tier or array.  Don’t worry about tiers if you’re just starting out!

The next thing to point out is the “Resource Kinds” drop down. This drop down is where we specify which resource we want to pull metrics for. By populating this drop down with a resource kind, the lists below it for size and color are populated. The section below the “Size By” and “Color By” lists refers to how we filter the data being returned. This would be a case where we wanted to possibly display the resource kind of Virutal Machine, but there were specific VMs we wanted filtered or not filtered. We could create custom tiers, applications, or any of the listed tags to filter appropriately.  The combinations in this area are essentially limitless.

The next section to highlight is in the top right on the color spectrum. You can see that there are two squares which allow us to customize the colors that show up during a range of values that are returned from the “Color by” metric selection. If these are left blank then the widget will take the maximum and populate the color manually. For percentages that are predictable for their health (utilization is a good candidate), it is always a good idea to fill in 0 and 70 for the range of green to red. However, keep in mind that some metrics may be reversed where being higher might not represent being worse and could be the opposite. In these cases you can press the box below the color spectrum to reverse the colors. You can even use a small trick to choose black for one of the left or right color boxes which (if you have dark set for user preferences) will make the box empty until you hit a certain point in the range. The black would reference no activity value instead of a good or bad value.

One last important thing to mention for heatmaps is around saving your configuration. Use the green plus button at the top right to create a new profile for each heatmap widget and configuration. When you have changed anything for this widget, either press the save button (disk below green plus icon) or press the green plus icon (for a new config).

The next widget that we will run through configuring is the metric graph widget. You can see here that there isn’t much to this one. You simply select a single or many resources from the list in the middle and then using the drag and drop method or the multi-select icon to bring the resource metrics up on the right. This is then followed by the same action, or the multi-select again to get the resources to the bottom list. You can then drag and drop those resources in the “Selected Metrics” window in the desired order.

You can see in the following screenshot that the legend at the bottom lists the values that we selected in the configuration. Defaulty, this widget may display the graphs individually in a list. However, we wanted to see everything overlayed together so we hit the button on the top left with the green and red lines which toggles between many and single metrics per graph.

An important thing to note with the graphing is the calendar portion of configuring the widget. There is a line and an arrow in the middle of the line above the graph. You can press this which will reveal the calendar portion to properly set the desired timeframe. We selected last hour in this example, but this can be whatever you want. Simply press the line with the arrow (divider) to hide the date selection.

Health

Health is an very important and useful feature within vCOps. Health relies on a lot of different metrics, their anomalies, and ties this together with context sensitive information about how relevant those metrics are to the overall health of the resource and its dependencies. The longer you analyze the metrics the better that vCOps can make good decisions about proper dynamic thresholds (DT) for that metric. All of the EMC metrics can contribute to the health of that resource over time. Let’s take a look at some different views that might help us dig through the health of resources.

For the following examples we will be leveraging the Health Status and Resources widget. These two widgets actually interact together so that we can at any time change the context of what we are viewing by clicking on the Resource List widget and have that change the view in the Health Tree.

We start by simply dragging the widgets over into the dashboard as described previously and configuring the health status widget. The only selection that we changed has to do with the Mode, where we set “parent”. This simply means that when this widget receives a request to change views that it looks at what was selected and then displayed the parents of that resource. It is important to make sure that “Self Provider” is not enabled here.

The next thing is to click the “interactions” button on the top right of the dashboard view.

This is where we can setup the relationship that determines where the actionable selection as mentioned previously gets displayed. In this case we are selecting the “resources” widget as the provider which means the health status widget will change context whenever we click a new resource in the list of the resource widget.

Go ahead and test this out once you save the configuration. You should be able to click through the resource list and have the information populated to the health tree widget.

Now the resource list that we are viewing may not need to be for all resources that vCOps has access to. If we want to limit the list this is a perfect situation to leverage a filter. The following is a list of proper filters for this example “Datastore,DISK,LUN_*,RAIDGROUP,SP,VIRTUAL MACHINE”. Remember the selection and de-selection process above the tag list. It never hurts to just use the de-select button (not red slash, that is reverse). We have also leveraged the order capabilities below the filter to make the list a bit neater for viewing.

With that complete you can now see the more friendly listing of resources and their health.

Now let’s take this to the next level. There are plenty of other widgets that can be added to this dashboard and viewed at the same time that might be useful. I added the Metric Selector widget which you can now see listed under the Interactions section of the dashboard. I am going to populate the metric selector with the resources as a provider. This will allow us to select a specific metric for a resource once it is selected.

You’ll also notice that we added a Metric Graph widget. We can select the resources provider in the top drop down, followed by the metric provider in the bottom drop down. This will give the metric graph everything that it needs to generate graphs on the fly as we click through our resources and metrics.

There you go, you can now see this dashboard coming to shape all properly related and interacting. Here we have chosen a resource. This resource has populated the parents above it. We then can choose a metric for the resource (double click) which then displays the graph below it.

Relationships

Another very cool thing that was slightly highlighted in the previous examples is around relationships. We demonstrated this capability by setting a “parent” for the health status widget. Let’s add a couple of more useful widgets to the dashboard that should better demonstrate what the relationships. We have added another Health Tree and a Root Cause Ranking widget. The interactions have then been set to be populated by the resources widget.

Here are the new widgets stacked on top of each other. We have selected the management datastore which would show us the immediate parents and children. If you have the EMC relationships or relationships with the resource you are viewing properly configured here (as I don’t) you would see the EMC LUN or NFS export listed below the VMware datastore (management). Below this health tree widget you can see that we are calling out the root causes for any health deterioration of the resource in question.

We are going to add one more health tree widget that allows us to take some pretty interesting views of the relationships. Where we previously were showing relationships based on the resources widget, we now can show relationships based on the actual health tree itself. This allows us to simple click a resource in the health tree which then populates the parent/child relationships in the new health tree.

Here is a view of that if it didn’t make sense when I described it. Here we are looking at the templates resource on the top. We then selected the “win7-basevm” resource which populated its direct parents and children. This would be a view that we would typically get if we double clicked the resource since the health tree itself will drill into whichever object we specify. By adding another health tree we can keep the top view stationary and explore relationships of any resource.

Here is a complete picture of the dashboard that we have created. You can see all of the widgets listed that we configured along with their dimension that was defined vertically per widget and horizontally per dashboard.

Hopefully this information is useful. I wouldn’t expect anyone to specifically use these examples exactly as is. The information presented is more for educational purposes so that you can go off and create your own dashboards!

I believe this can be approached from the top down where we first start to understand where VMware is going with their cloud solutions portfolio.  Let’s begin by focusing in a specific area such as Applications.  If you’ve been a part of virtualization over the last handful of years a trend has started to become very clear (it’s coming, yes the big c-word).  As we virtualize pervasively across all different aspects of infrastructure,  from the operating system, virtual hardware, storage, networking, compute, and just about all other areas there is a common theme that we are driving towards.  We are seeing a lot of organizations working feverishly  towards the bigger theme of cloud.  In this thought I am referring to cloud in how we expect technology to be agile, elastic, and scalable unlocking different ways for organizations to consume and deliver applications to their end users.

When we look at Infrastructure, Applications, and End-User computing together we start to get a view of what we’re working with.  The truth of the matter however, is that it is our users that keep the roof on the head and it is the applications that an organization provides that allow them to be efficient.  So for this reason we focus highly on how we can make the applications as agile as possible.  This refers to the notion that an application can be ran from anywhere on anything with a minimal amount of physical requirements, and the thoughtlessness involved in having transparent automation to accomplish successful deployment.  In order to accomplish these things it requires that we start to move away from physical definitions of requirements such as networking hardware capable of value-add features, to providing these same purpose built services in the virtual world and having these services portable or defined alongside an application.  Are we referring to a Virtual Application here?  No, we are referring to an Application that leverages Virtualization to be agile, elastic, and scalable.  There is are other trends of course out there, but let’s focus..

So let’s take a step back to what a Virtual Appliance is in the general Hypervisor world.  A VApp in the previous and short term has typically been known for a couple of things.  The first being the ability to be downloaded as a pre-built, pre-configured, VM or set of Virtual Machines, that can be consumed from  a VMware “store (marketplace)” or other location.  Once a VApp or OVF (Open Virtualization Format) is downloaded the next concern is how the VApp is operated.  This being a set of Virtual Machines grouped together, we paid high attention to setting a start order, defining IP addressing (basically a wizard driven process), all constrained by a certain resource consumption policy.  These two things of downloading and operating being directly related of course.  In continuing our thoughts around how VApp’s are growing up, I now draw a connection from cloud to VApps.

When I previously said that our usage of the term cloud was around being “agile, scalable, and flexible.”  The idea of an existing VApp didn’t necessarily directly promote those concepts,.  So if I was going to make a VApp to meet these “Cloud” concepts for vCloud Director it would make sense to start from scratch and think about this a bit differently.  We would have to begin to think about what we can contain in a VApp container that would help to make our applications function anywhere, without limitations or physical requirements.

In the rest of the post I will look at the following major areas.

• VApp Networking
• Service Definitions
• VApp Templates and Catalogs
• Resource Pools
• Fast Provisioning
• For good measure—The vSphere VApp

VApp Networking

The first major difference between vSphere and vCD is the inclusion of optional VApp networking.  If you’re brushing over this one, it’s actually a HUGE topic.  vCD itself introduces many new levels of network virtualization.  These levels can be defined as External Networks, Organizational Networks, and VApp Networks.  In referring to these new networks vCD is providing a couple of major fundamental shifts in how we think about running Virtual Machines.  The first is SDN (Software Defined Networking) where through invisible usage of vShield Edge devices, isolation, and L2 tunneling is achieved without the need for massive amount of VLANs and special networking configuration under the covers.  The other major contribution is around services being deployed, also in an invisible fashion, to service applications or the isolation of VMs.  When thinking about what an application requires to function it basically boils down to a few things.  How am I going to provide proper isolation while leveraging my pool of compute, how can I ensure security among my VMs, and how can I provide services to these VMs that contribute to their operational qualities or remove physical dependencies.  This would all be typically done by physical devices.  Defining these as services for the VApp make for an ultra portable and scalable application.

Below is a VApp with a VApp Network defined.

Notice the following VApp diagram where we now have services defined (firewall, NAT) which connect externally to a organization network.

This is defined simply by the following screenshots and repeatable within a VApp or VApp Template.  Here you can see that we have defined a VApp Network and it included NAT and Firewall services with an external connection to orgNetwork.  The “192.168.0.1” services as our inside default gateway of the vShield Edge device shown as a firewall icon in the VApp diagram.

Here you can see that we have defined stateful TCP services for allowing RDP inbound and allowing all traffic outbound from the VApp VMs.

This screenshot show the NAT services that we have specified.  The choices here are “IP Translation” or “Port Forwarding.”  Under IPT an IP address is created on the external connection for every VM that is turned on or specified.  Conversely, under “Port Forwarding” we simply manually specify which VMs and 1:1 rule of outside port to inside port is created on a single IP.

This is another important one.  Notice how we define other interfaces as DHCP?  This is to support SDN.  Consider it this way, if I am wanting to create a policy for a VM in a firewall then the firewall is going to ask a simple question.  What IP and what port/protocol?  In order for vCD to communicate this it needs awareness all of the time with 100% certainty in order to be reliable.  This basically means that the old trick of looking at a VM’s IP address via VM Tools won’t fly anymore.  The requirement for repeatability is that vCD defines this information or you manually define this information for it.  This is one of the purposes of IP Pools in vCD.  In this case we have defined the nic0 of “vpodrouter v3” and the IP Mode as Static – Manual.  We have then set the guest IP to match this.  All other VMs in the VApp are set as “DHCP” and as long as we don’t attempt a customization this setting will not (and should not) be forced down to our VApp VMs.  Long story, but this is a detail around IP configuration takes some first hand to fully grasp.

Look at these emerging technologies.  I am simply defining them in terms of VApps here.  Take the same though to the virtual datacenter and ask yourself what that vDC would require to be cloud capable?  L2 extensions? Highly available firewalls? High throughput? A lot of discussion here!

Service (Section) Definitions

Now let’s get back to differences..  A great way to view some of these is to use PowerCLI and start navigating the two commands (Get-VApp/Get-CIVApp and Get-View/Get-CIView).  One of the first things that popped out at me was the idea that the “services” that are being provided by the VApp Networking were being defined dynamically.  By dynamically, I mean that instead of an Object having hardcoded Firewall, or NAT Policies, this information is all contained in a “Section” parameter which adheres to a general definition to support any number of things.  This is where I start to put my technology cap on for a second.  We briefly discussed VApp Networking and SDNs.  This is clearly visible here (NetworkSection,NetworkConfigSection).  The question that I throw out here is what else would be relevant to a VApp that can be defined dynamically?  Here’s the framework to make it happen!  An array of Section objects that can define any number of services provided to a VApp.

(Get-CIVApp name | Get-CIView).Section | select Href | fl *

VApp Templates and Catalogs

In comes another new but familiar term.  Instead of thinking of things as VM Templates, in vCD we refer to them as VApp templates.  This is the case even if there is only a single VM in the VApp template.  Do I still need to define services associated to this single VM?  There is always the option to opt-out of these services where Networking can operate in a simple “bridged” mode versus the “NATRouted” mode.  With that said the VApp template is now the container that gets checked into a Catalog and serves as your Gold Copy for all preceding deployments of your VApp.  Is this required? No you can still simply “Copy” VApp’s in order to spawn new copies.  However, it is a way to share VApps between organizations.

Here you can see a Catalog populated with versions of our “Base” ePods.  These are a collection of VMs that serve as a starting point from a networking and functional perspective for labs that we might offer.

Resource Pools Are for Provider/Organizational Virtual Datacenters

I haven’t quite stepped into what a Provider and Organizational Virtual Datacenters are.  In one line, a PvDC maps to a cluster or possible physical location and an OvDC maps to a PvDC.  An Organization currently (v1.5) creates an OvDC per PvDC that they would like to consume from.  VApps are then deployed to OvDCs where an organization can have multiple OvDC’s differentiating either applications, departments, SLAs, or any number of different things.

This is a big one.  In vSphere, VApps were essentially just Resource Pools under the covers with extra metadata.  The metadata included things like startup order, and the Resource Pool allowed for native ability to segregate resource consumption for the set of VMs.  In vCD the resource consumption is controlled most directly to the VApp at the OvDC level.  So this only makes sense that an OvDC is simple just a Resource Pool right?

This is how vCD consumes the vSphere folders/hierachy.  In this case, you can see our two nodes of the cluster at the top.  Underneath that you can see the C01-RP which is where our Provider vDC is tied in.  And below that we have OvDC_HOLDEV_C01 which is our first Organizational Virtual Datacenter.  From there you simply see VMs with certain unique identifiers that vCD uses to track after the VM names and a special icon.  So what is the main difference?  If not using vCD, the VApp (Resource Pool) would contain only the VMs of that VApp and the VApp (Resource Pool) would define extra metadata.  In vCD a Resource Pool is used simply to martial resources and is again tied directly to an Org vDC.  You can see below that we have 15 or so of the same VM’s running, which means that we have 15 VApps running with that VM in vCD.

Fast Provisioning

As of vCD v1.5 Fast Provisioning is now an option along with a the legacy Thin provisioning capabilities.  Although this is more technology directly aligned towards a VM itself, it is also important to mention that it does function with a VApp construct.  Fast Provisioning is the capability to leverage linked clones at the VMDK level.  This basically creates a new delta disk file for each new VM that is fired up and instantiates any changes this new VM introduces (writes) into the new delta VMDK.  First off I am an EMC employee for this one, YES we highly support the use of linked clones with vCD.  They improve the locality of IOs (better for caching), are space efficient, and are quick to deploy.  Fast Provisioning can actually be thought of as a capability to snapshot in vCD (snapshotting VMs is not natively supported).  By this I mean you can simply check a new copy to the catalog or copy your VApp in order to create a quick snapshot (no quiescing, VApp needs to be shutdown).  Leveraging FP for snapshots is more useful is certain circumstances like labs, VApp development, versioning, than it is in production deployments.  I will expand greatly on how FP looks under the covers in a upcoming post.  For now VApps are FP aware, so all VMs are copied at the same point in time using linked clones.  In vSphere, this was API driven from the VM level.

For good measure–vSphere VApp

The following is a traditional vSphere VApp which would be repeated any number of times.

You can see here some basic resource consumption policies, custom properties, IP Allocations, and Application specific properties.  Other tabs listed are Startup Order and vServices.

The vServices is a new one with vSphere 5.0.  Could it someday also allow for defining network services for a VApp?  Probably not.  Don’t underestimate the amount of work it takes to properly automate and implement SDN.

That’s all!  This has been a bit of a departure from my typical PowerCLI blogs but hopefully worth a quick read for anyone interested in the topic.  Stay tuned for more vCD goodness!

What the heck is an OVF?  An OVF is an open standard for distributing virtual machines.  The open standard should help standardize the formatting of a virtual disk, describe how a virtual machine needs to be configured to be re-assembled in other systems, and possibly describe an application configuration or custom properties that can be configured to make the VMs and vApp unique and/or function.  This open standard should make it a snap to transfer in between different hypervisors, and hopefully first off within the same family of virtualization technology.

So if you’re like me then you probably expected that an OVF is the same to vCenter/vSphere as it is to vCD.  Well, at the moment it’s not so and a vApp is currently (v1.5) technically not the same =( 

This post should provide an option for navigating this mess and at least being able to get OVF’s constructed as packaged vApps to function in vCD. 

vCloud itself has native functionality to import OVFs as vApps.  The following screenshot was taken by navigating to a catalog, right clicking anywhere inside of the open catalog inventory and selecting upload.  You can see that a Java window opens with the following questions around  he OVF package location, name, and description.  Upon selecting the appropriate options and saying upload, the transfer process begins where the virtual disks from the OVF are copied to the transfer directory of the vCD cell, configuration is consumed,  followed by another copy up to a provider vDC datastore, and a final configuration of the vApp.

In comes the problem with OVFs!  In order to understand this we need to see how OVFs are generated.  I am going to present this in two export methods from VMware technologies.  First though, the native vCD “Download” functionality where you can simply just right click a vApp Template and save the descriptor.ovf and associated files to a directory using the Java applet from vCD.  This *should* be the most native way to reimport a vApp to vCD.  The second way is more the legacy method where you export a vApp/VM from vCenter and/or possibly use OVFTool to construct a vApp where you assign custom properties that a user should answer during the import process.  The custom properties I am referring to may be to accept a license agreement, the hostname, IP address, subnet, gateway, etc. of VMs being deployed.  These custom properties are where the problem comes into play. 

Warning: What I am describing is something that I ran into so there are probably more ways to get around this and I probably am not presenting all the information correctly, but here goes..

The custom properties that are associated with an OVF seem to somewhat be incompatible (v1.5) with a standard “Upload”.  If there are custom properties, or internally called the “ProductSection,” the upload may fail with the following errors and screenshots.

“Error: Validation failed for the OVF file you provided”

“complex-type2.4.a: Invalid content was found starting with element”

“Error: The manifest of the OVF package is invalid”

So what do you do in this case?  The easy way that I have gotten around this is to first import the OVFs into vCenter and then utilize the “Import from vSphere” functionality to get the individual VMs into a vCD vApp.  This will allow you enter the OVF custom properties via vCenter as you normally would.  However, keep in mind that the custom properties will still be associated to this VM, but you shouldn’t have any problem getting the VM imported this way.  I suggest booting the VM up and then stopping it in vSphere following the standard “Deploy OVF Template” process.

Now you may be thinking, hey that isn’t so bad?  I got my VMs into the vCD vApp! Well it gets better.  As mentioned before the custom properties may still persist so the problem can now effect the startup of the VM in vCD since it doesn’t play nice with some of the custom properties from VMs brought into vCD from vSphere and previously imported as OVFs.  So what to do?  Pop open your vApp in vCD, right click and go to properties.  Do you see custom properties listed?  If so then you might have a problem.  Try filling these in and try and boot the VM.  Like Below?  Well for this of course we have Powershell and PowerCLI to the rescue!  Below is an error that you may run into if there is invalid custom properties.  Notice the “Invalid vApp Properties: Unknown property” error.  This is followed by other errors where the process then tries to roll itself back and runs into errors doing this.  Trying to start a vApp unsuccessfully may lead to having to go to vSphere and manually stop the other VMs in the vApp and/or delete a portgroup manually.

Here is a quick look at what custom properties or “ProductSection” could possibly cause problems inside of the OVF file.  Can you modify the OVF file ahead of time to make this easy?  Probably, but I decided to go about it a different way.

So as usual I have built a custom cmdlet using the PowerCLI cloud methods.  Following are the requirements.

• PowerCLI 5.0.1 (Cloud selected on install)
• Download the new custom powershell module here.
• Run Connect-CIServer vCDInstance
• Run Import-Module vcd_custom5.psm1

*New Remove-CICustomProperties* This cmdlet will remove custom properties other than a single “ProductSection” relevant to the VM itself.  Use at your own risk!

Example- Remove Custom Properties from a Virtual Machine named “name” in a vApp starting with “Google”.

Get-CIVApp Google* | Get-CIVM name | Remove-CICustomProperties

The following screenshot is what a VM in a vApp inside of vCD should look like from the “Custom Properties” tab.

And that’s it!  From there you should have no problem starting this VM.  If you are running into errors around the dvSwitch then you can either manually remove the associated dvPortGroup, create a new vApp and move the VMs into this vapp, or check the vApp into the catalog and redeploy it from the catalog as a new vApp.

What does this mean?  Well I’ll have you read through his post, and even give it a shot =) Then give what you see below a try and it might shed some light on how effective good frameworks can be on top of APIs.  This goes back to one of my philosophies around APIs.. they’re great, but if you truly want adoption you need to write frameworks or command line functionality on top of it to make it scalable.  Without this it is only for the 1%’ers who have the time to read the docs and can do those types of calls. =)

What you’re going to find below are four new cmdlets for PowerCLI.  As usual see the requirements.

• Downloaded the module here.
• PowerCLI 5.0.1 with Cloud selected on install
• Import-Module vcd_custom4.psm1
• Connect-CIserver vCDInstance

*New New-CIMetadata* Create new metadata associated to whichever vCD object is passed.  See William’s post as mentioned at the top for other links around which objects are actually valid to tag Metadata to.

*New Get-CIMetadata* Retrieve metadata for a specific vCD object.

*New Remove-CIMetadata* Remove metata assocaited to whichever vCD object is passed.

*New Update-CIMetadata* Updates metadata for a vCD object’s own metadata.

Now if you’re interested in how we made this happen keep on following on.  For those that just want the unofficial metadata cmdlets you should be good to go.

When exploring for unadvertised features in PowerCLI the first thing I always do is look through the views or ExtensionData from the object.  You can see this below where I issue a “| gm *” after the view which is short for Get-Members *.  The returned information is based on available methods and properties.  The methods are all callable based on the definitions.  This is the first hint that there is a lot of beef behind the Cloud assemblies for PowerCLI.  Looking through the list you can see the GetMetadata methods, perfect!

With that method found, let’s start to use it.  The following screenshot is a call to the method.  You can see that we then have the metadata keys returned under the MetadataEntry parameter.

However, what’s important here is that we are looking for something that might say “UpdateServerData.”  If this was there I would be able to set the parameters directly and then call this method to actually post the changes.  In this case that method doesn’t exist and instead there is actually one called SetMetadataValue.  Wallah, there you go.

Here are the specific Metadata entries that were stored in the MetadataEntry parameter.

And the next section is actually a sample of what I would do to create a new metadata item.  Notice how when we call SetMetadataValue for this first time it tells us the required parameters (key,value).  In the next line we call it as it required and then check to see if it exists.  Perfecto, all done.

All in all I want to thank William and the PowerCLI team for implementing a lot of the vCD API.  Although the cmdlets aren’t quite fully baked yet it looks like we will have a pretty rocking Powershell interface to vCD in the short term!

So here we go, as usual see requirements below. 

• PowerCLI 5.0.1
• Download the module here.
• Import-Module vcd_custom3.psm1
• Connect-CIServer vCDinstance

*New New-Catalog*

Creates a new catalog by specifying the name of the catalog, the name of the organization and whether to publish (not in screenshot).

*New Remove-Catalog*

Removes an existing catalog from an organization.

*New Add-CIVAppToCatalog*

Adds an existing VApp to a catalog.

That’s all for now.

When deploying applications in vCD the combinations of external, organizational, and vApp networks are limitless.  Depending on what the target operating environment is you might need to apply NAT at multiple levels or simply just bridge the networks together which would mitigate any networking multi-tenancy concepts.  Other specific use cases may specify that you not create multi-tenant organizational network divisions, but more specifically a NAT per deployed vApps.  This use case may be aligned towards a lab (hmmm… what’s coming up in May for EMC? And what do we offer there in massive scale?).  Thanks Clair Roberts, Curtis Pope, Everett Golden @VMware Integration Engineering for providing some guidance here. 

In proceeding down this path of leveraging vCD for possibly a lab environment I was able to look at a successful lab scenario (VMworld 2011) that leveraged vCD and looked into what it might take to achieve the same automation in Powershell.  To be successful it is hard to communicate the amount of detail that goes into the backend equipment and vCD design.  As far as vCD we break this into two areas, one for how we support the development of the labs and one for the operational aspects of active labs.

This post is going to demonstrate how we can provision from a catalog including the vApp Networking details that apply NAT for obfuscating vApp VM details, and firewall policies for allowing RDP connections into the vApp.

So let’s dig into it, get the next version of the functions for Instantiation-VApp cmdlet here. ***

The new options that are included in this version have to do with the vApp networking for DHCP, Firewall, and NAT services.  See the example parameters below when deploying a vApp.  If you are not concerned about the details around how the vApp networking is configured, or you are going to leverage NAT possibly at the organizational level then you can skip everything at the –fencemode and below lines which aligns more with the previous post.

# Instantiate-VApp -name "test" -catalogname HOLDEV_HOL22_CAT01 -vappname HOL22-Test-v1 -orgvdcname OvDC_HOLDEV_HOL22_C01 -hashNetworks @{0=@{sourceNet="orgNetwork_EXTERNAL01_HOL22_C01";targetNet="orgNetwork_EXTERNAL01_HOL22_C01"}} -fencemode "bridged"

# Or

# Instantiate-VApp -name "test" -catalogname HOLDEV_HOL22_CAT01 -vappname HOL22-Test-v1 -orgvdcname OvDC_HOLDEV_HOL22_C01 -hashNetworks @{0=@{sourceNet="orgNetwork_EXTERNAL01_HOL22_C01";targetNet="orgNetwork_EXTERNAL01_HOL22_C01"}}

#    -fencemode "natRouted" -natRoutedIpScope @{IsInherited = $False;Gateway = "192.168.100.1";Netmask="255.255.255.0";Dns1=$null;Dns2=$null;DnsSuffix=$null}

#    -IpScopeIpRanges @(@{startAddress="192.168.100.100";endAddress="192.168.100.199"})

#    -DhcpEnabled $False

#    -DhcpIpRange @{startAddress="192.168.100.2";endAddress="192.168.100.99"}

#    -DhcpDefaultLeaseTime 3600

#    -DhcpMaxLeaseTime 7200

#    -FirewallEnabled $True

#    -FirewallRule @(

#       @{IsEnabled=$True;Description="RDP";policy="allow";protocols=@{any=$null;icmp=$null;tcp=$True;udp=$null};port=-1;destinationip="Any";sourceport=3389;sourceip="Any";direction="in";enableLogging=$False},

#       @{IsEnabled=$True;Description="Allow all outbound traffic";policy="allow";protocols=@{any=$True;icmp=$null;tcp=$null;udp=$null};port=-1;destinationip="Any";sourceport=-1;sourceip="Any";direction="out";enableLogging=$False}

#       )

#    -Nat @{NatType="ipTranslation";Policy="allowTraffic"}

So in summary, if you use the parameters above when deploying from a catalog you will be deploying a vApp with a vApp networking leveraging the “natRouted” mode to provide separation from other vApps.  All connectivity to the outside of the vApp will be provided by the “orgNetwork_EXTERNAL01_HOL22_C01” network which can be anything.  See the previous post listed above if you need more details on the parameters before “-fencemode”.

*New Instantiate-VApp* This function looks for a specific VApp Template that resides in a catalog of an organization and creates a new VApp in a specific Organizational vDC.  The following is what the parameter section looks like for runtime options.

    Param (

        $Name=$(throw "need -name"),

        $CatalogName=$(throw "need -catalogname"),

        $VAppName=$(throw "need -vappname"),

        $orgVdcName=$(throw "need -orgVdcName"),

        $hashNetworks = @{},

        $LinkedClone=$true,

        $AllEULAsAccepted=$true,

        $IsSourceDelete=$false,

        $Deploy=$true,

        $PowerOn=$true

    )

The parameters are pretty self explanatory, but if needed you can get some more information from the official vCD REST API guide here on page 33.  The –name parameter is for the new vApp, and the VAppName is the template name.  The piece that needs some expanding on is the $hashNetworks portion.  Here we are using a hash table that is issues as follows.

-hashNetworks @{0=@{sourceNet="ALL_PURPOSE";targetNet="BBS_external01"}}

The important thing here is that we need to map the VApp template network connections to the proper network in the destination Org vDC.  For this we create a hash table based on an integer index (unique network names, not network adapters), and sourceNet/targetNet parameters under those indexes.  So in essence, an array of hashTables with sourceNet/targetNet specified for mapping the two.  A two index hash table would look like the following.

-hashNetworks @{0=@{sourceNet="ALL_PURPOSE";targetNet="BBS_external01"};1=@{sourceNet="Internal-NoUplink";targetNet="BBS_internal01"}}

The following is a screenshot of the script in action where we actually can choose not to specify –hashNetworks if we want to specify this manually after deployment or we are deploying to a vDC that has the network names that the vApp template currently has.

Otherwise we would run the command like follows.

In the good spirit of leaving bread crumbs for all of those fellow Powershellers out there, the function that I built leverages the calls that are a part of the OrgVdc object.  This functionality is exposed via issuing a Get-OrgVdc cmdlet follwed by calling the Get-CIView cmdlet and then a method that is available called InstantiateVappTemplate.  Previous to the method being called, we also built out the $paramsVAppT object to contain necessary required fields.  These required fields were pulled and transcoded pretty much line for line from the official vCD REST API guide here on page 33.   Hopefully following this function you can either make this cooler, or implement completely different use case.

(Get-OrgVdc $orgVdcName | Get-CIView).InstantiateVappTemplate($paramsVappT)

Alan has a good post on some basic functions that can help to achieve some basic things all leveraging exposed methods under the covers.

http://blogs.vmware.com/vipowershell/2012/03/automating-creation-of-vcd-organizations-users-and-org-vdcs.html

My intent for this post is to add a few more cmdlets to the public that may be useful for certain circumstances and might even be more useful with a bit of tweaking for yourself.  My use case here was to be able to create an organization, an organizational vDC, create groups for the organization, and set LDAP appropriately to allow an LDAP security group access to that organization.

Requirements are as follows:

• PowerCLI 5.0.1 (with vCD cmdlets selected on install)
• The unofficial vCD module I created here.
• Run “Connect-CIServer”
• Run “Import-Module vcd_custom.psm1”

*As Is* New-Org The following screenshot is based on work from Alan Renouf from the link listed above where we simply create an Org.

*New* Set-OrgLDAP The following cmdlet will set the SYSTEM LDAP setting for an Org.  Before running this we are expecting that you have LDAP configured on the main portion of the vCD Administrator page (outside of an Org) and that you have used the test LDAP functionality in the setup area.  The SYSTEM setting leverages the existing LDAP information from the main vCD instance for the child Org.

*New* New-OrgGroup The next portion here will create a new organization group based on a certain LDAP security group name and an existing vCD role name.  I haven’t had a whole lot of time to test this part, but I did find that in order to get the LDAP sync’d for the org created I had to restart vCD.  Unfortunately I am using 1.5 and not 1.5.1 for specific reasons so am not sure if this is a bug or if I need to wait an indicator saying LDAP group adds are ready.

*Modified* New-OrgVdc2 The following cmdlet is a spin off of another one that Alan created except I am using a different parameter, –FromOrgVdcName which will allow us to specify a model OrgVdc.  This simplifies the parameters specified since we copy the important stuff from an existing OrgVdc.

That’s it!  Pretty quick and dirty examples of how to automate some more detailed setup tasks.  I would assume we will see a lot of this stuff get rolled out in the near term in official cmdlets, so this should only be temporary.  Stay tuned to the blog as I have a good amount of vCD automation work that might be popping up here shortly.

When running PowerCLI cmdlets, some include the ability to asynchronously run which means that they get sent to the background and processed while allowing to run more commands.  This parameter can be invoked by specifying “-runasync:$true”.  This can be very handy if I have a single PowerCLI cmdlet that I want to execute many times with a predetermined set of data, for example to stop all VMs as quicky as possible  “get-vm | Stop-VM -runasync:$true -confirm:$false”.  But what about a situation where I might have a set of commands that need to be run asynchronously?

This is where leveraging the jobs portion of Powershell to launch multiple PowerCLI sessions helps.  With this method we are reusing the existing PowerCLI session token and launching new instances of PowerCLI  to accomplish many tasks in sequence that are all tied together possibly similar to a workflow.

So if you’re interested in seeing this in action, continue on.  Firstly the below is a summary of some of the useful tidbits you will see in this example.

• Optimizing Powershell and PowerCLI for speed
• Reusing VIServer credentials based on session token
• Executing differently if PowerCLI is loaded and/or credentials specified
• Multi-threaded PowerCLI

One of the goals of multi-threading is to be able to perform more actions than executing in a serial fashion.  For this reason I assume that you are looking to minimize the average time per execution of PowerCLI.  So to begin with I highly suggest reading a previous post of mine which walks you through how to optimize Powershell and PowerCLI execution times here.  This also has a huge effect on the CPU as if you do not optimize, when PowerCLI starts it will perform compilation operations that eat a whole core of your CPU for 10+ seconds.

Now with that behind us let’s get into the details of credentials.  When logging into a VIServer in PowerCLI the session creates and stores a specific token secret token.  See the screenshot below for retrieving this token.

We will be reusing this token by passing it to the script that is the target of our multi-threaded execution (in the job) which replaces the need to re-login to create multiple sessions under the same username or pass credentials to the job.

The next important demonstration is pretty common and others may have different approaches.  It involves being able to load/not-load PowerCLI and Connect/Not-Connect based on whether it is needed or not.  For example, if we launch the child job script then we will need to load the PowerCLI snappin on the fly.  But if we want to keep the script the same even if PowerCLI is already loaded (for execution outside job)  then we want to do a simple detection for the existence of the cmdlets. 

The following is a re-useable section of code that you can use to simplify detection of PowerCLI and existence of a login.

if(!$global:DefaultVIServer) {

      if(!(get-pssnapin | where {$_.name -eq "vmware.vimautomation.core"})) {

        try {

            add-pssnapin VMware.VimAutomation.Core -ea 0| out-null

        } catch {

            throw "Could not load PowerCLI snapin"

        }

    }

    try {

        connect-viserver $vcserver -username $vcusername -password $vcpassword -wa 0

    } catch {

        throw "Failed to connect to VI server"

    }

}

Ok so now let’s move on to the more exciting stuff around multi-threading.  The first portion of what we do is set our current path variable.  This is necessary because when loading a new Powershell instance the current path changes to your profile’s set path.  What we want is to set the path based on where the script is being executed from.  For this we issues to following command in the control script and then pass it to the job.

$currentPath = (Split-Path -parent $MyInvocation.MyCommand.Definition)

So you may be asking, why would we not just use the invoke-item cmdlet or have the job kick off the script without the new Powershell session?  In testing I found that I was getting random errors from PowerCLI cmdlets and methods.  I am not 100% sure why but I believe it has to do with the jobs executing with a console.  Creating a new Powershell instance that PowerCLI can execute under solves this.  Keep in mind the memory usage per thread which can be 60+MB.

Anyways, the next portion is the scriptblock that will be executed when we kick off the job.  Notice the first line, “set-location $args[0]”.  This takes the path that we got from above and has the child kob instance reset its current working directory.  We are passing two parameters to the script, the first being the session to be reused, and the second being the  destination vcserver.

$job = {

    set-location $args[0];

    powershell -command ".\powercli_example_cmd.ps1 -session $($args[1]) -vcserver $($args[2])"

}

The following line is how we kick off the job.  Notice the “-argumentlist” where we specify the parameters to be passed into the $job scriptblock.

start-job -argumentlist $currentPath, $session, $vcserver -scriptblock $job | out-null

Before kicking off the job we need to build our powercli_example_cmd script.  This script will be responsible for loading the PowerCLI snapin and logging into the VC server with the existing session.  Notice the line for connecting with the “-session” parameter.  This script also includes our workflow, serial steps of commands, or in this case a single command that returns the first VM found to the job output.  An important note here is that the output of the job sent from receive-job comes through in arrays of strings.  So you can either send the output in something like JSON or simply grab what you want like the VM names (| %{ $_.name }) which is easily parseable.  If using this simply to execute methods then this warning may not be valid.

param($session=$(throw "missing -session parameter"),$vcserver)

if(!$global:DefaultVIServer) {

      if(!(get-pssnapin | where {$_.name -eq "vmware.vimautomation.core"})) {

        try {

            add-pssnapin VMware.VimAutomation.Core -ea 0| out-null

        } catch {

            throw "Could not load PowerCLI snapin"

        }

    }

    try {

        connect-viserver $vcserver -session $session -wa 0| out-null

    } catch {

        throw "Failed to connect to VI server"

    }

}

get-vm | select -first 1

Ok, so let’s move into actually running the jobs.  In order to execute the job we are leveraging a foreach loop as “1..2 | %{ .\powrcli_mt_control.ps1 –vcserver ip”.  This means run this command twice.  We can then leverage the get-job cmdlet to see the status of the job, as you can see below it is running and then turns to completed.  Once it is completed we can run “get-job | receive-job” to see the output.  Review the help for these cmdlets as there are some gotchas.  For example if you run the get-job | receive-job it will trip the “HasMoreData” to $false until more data comes in.  Long story, just play with it a bit to get comfortable.  When done with the jobs issues a “get-job | remove-job” to remove the existing jobs.

I’m afraid that’s all for now!  I am using this very successfully in order to multi-thread some pretty massive workflows all built within Powershell leveraging PowerCLI.  Here are the example scripts.