While I’ve been head down in the final edits for the vCO book (Pre-Order here), a few things happened in the vCO community.

vCO Happenings

• vCO Training! – vcoteam.info
• Unattended vCO vApp deployment – vcoteam.info (manual deployment here)
• Getting started with vCO – PhilipSellers.com, a good getting started piece.
• vCO Training Videos – vmware.com

More vCO Resources

As always, check out my vCO Resources page for all manner of resources from deploying the vCO vApp to plug-in info and helpful workflows.

In case you missed the announcement, the barrier to entry for vCenter Orchestrator was just lowered significantly with VMware’s release of the vCO 4.2 vApp. Here, we’ll talk about installing it.

Installing the vCO vApp

Assumptions

Basically, I’m assuming that you have an edition of vSphere that is licensed for vCenter and have downloaded both the OVF and VMDK files from the VMware download page:

Installation

Once you have the bits, do the following:

1. Fire up the vSphere client, login.
2. File > Deploy OVF Template…
3. Aim the wizard where you put the files:
   
4. Accept the EULA
5. Give it a Name & Location
6. Pick your host/cluster
7. Storage
8. Disk (it’s all greyed out)
9. Properties (This is where you set your static IPs):
   
10. Done!

Configuring

Even though most of the vApp comes configured out of the box, there are still some additional steps you need to do once the VM has been deployed:

1. Select the VM in the client, locate the IP:
   
2. Point your web browser at that IP:
   
3. Now, pick “Appliance Configuration”. You will be prompted to change the default password:
   
4. On the next page, log in as root, and you’ll be presented with the following:
   
5. You will need to do the same password change for the vCO configuration page. This time log in with the default of vmware / vmware

Logging in

1. Start on the default page for the vCO Appliance:
   
2. Start Orchestrator Client (The client is in Java, and will launch the Java Web Start bits):
   
3. Log in with vcoadmin/vcoadmin
4. Accept the SSL cert.
5. Done!

Summary

Long blog post is long. To put it in perspective however, it took me 8 minutes from start to operations not including the download. For more info on Orchestrator, check out my past posts here. You should also pre-order the vCO Book here. If you have any questions or comments, feel free to drop a line.

Yes! You can! I’m not talking about using vCO to call PowerCLI scripts. As well, that’s been covered before. What I’m talking about is using PowerCLI against VMware Onyx to get vCO JavaScript (Jeorg Lew’s post on it here).

First, get Onyx. I’ll wait… Have it? Excellent. Now fire it up & change the output mode to vCO JavaScript:

Next, open a new connection and select PowerCLI as the client:

Once connected, run some of your PowerCLI commands. The example below is from running “Set-KeyDelay.ps1” script from a while ago. Output from Onyx below:

// ——- ReconfigVM_Task ——-

var spec = new VcVirtualMachineConfigSpec();
spec.extraConfig = System.getModule(“com.vmware.onyx”).array(VcOptionValue, 1);
spec.extraConfig[0] = new VcOptionValue();
spec.extraConfig[0].key = “keyboard.typematicMinDelay”;
spec.extraConfig[0].value = 2000000;

managedObject.reconfigVM_Task(spec);  // VirtualMachine

It’s that Cody guy again, and well he’s late to the announcement party again… Busy is as busy does, but that said, in cleaning out my feed reader I found the following Gem:

Check it out here. Note the little bit at the bottom:

That’s right… vCO Plug-In docs on your e-reader of choice.

There has been a lot going on in the vCO space while I’ve been head down in the book. No excuse to not post about it however. This post is all about the plug-ins:

VMware posted here about the vCenter 5.x plug-in:

As promised in a previous post, the vCenter Server 5.0 plug-in adds over 50 out-of-the-box workflows to extend capabilities around networking and storage operations, and to incorporate new features like Storage DRS into fully-automated, end-to-end cloud provisioning scenarios.  As previous versions, the plug-in provides 100% coverage of the 5.0 vSphere API.  With this new plug-in, organizations can now automate a broader number of use cases, such as dynamic scaling-up and scaling-down of vSphere resources, while taking full advantage of the new vCenter Server 5.0 capabilities.

More info & release notes here.

They’ve also released the SNMP plug-in:

With the SNMP plug-in, you’ll be able to define policies that automatically trigger specific workflows when SNMP traps are received by vCO. For instance, an administrator could configure a workflow that, upon detecting that a vCenter datacenter is nearing full capacity, would reclaim unused resources or provision additional compute and storage resources.  Of course, the SNMP plug-in is able to process events beyond vCenter Server, so the triggers for workflows can come from virtually any device or system that supports SNMP.

More into & release notes here.

Also, don’t forget that there is a plug-in site on vmware.com that can be found here.

For those that couldn’t make it to the live show, be heartened to know that what we did was a live version of this BrownBag.

If that’s not enough… brace yourself for some really awesome stuff, right here:

The Slides

They’re not much to look at because well, it was a demo heavy session. That said, here you go:

The Demos

Demo the first:

VMworld 2011 – PowerCLI 101 Demo1 from ProfessionalVMware on Vimeo.

Demo the second:

VMworld 2011 – PowerCLI 101 Demo2 from ProfessionalVMware on Vimeo.

Demo the third:

VMworld 2011 – PowerCLI 101 Demo3 from ProfessionalVMware on Vimeo.

Summary

For the full effect you will have to wait till the VMworld bits are published, and even then, will have to have attended the show. However, the above should get you a pretty good start. If you have any questions or comments, drop a line in the comments. Also, twitter here.

Was surprised this wasn’t here by default, but alas, out of the box vCO does not ship with a workflow to manage an NFS datastore.

Thanks to the VMware communities for a bit of scripting, I was able to put one together. First we’ll break out the components, then show you how it runs. Finally you’ll be able to pull it down.

Inputs:

So first we need to tell vCO where to find the NFS datastore as well as what host we are adding it to:

If you can’t read the above, no worries, I can’t either, so I’ve also got this handy table:

Name	Type	Description
Host	VC:HostSystem	Host to connect datastore to
DatastoreName	string	Name for Datastore
remoteHost	string	Hostname or IP for NFS server
remotePath	string	Path to Exports

Schema:

Now that we have our inputs, let’s build out the actual flow-charty bits for the workflow:

Yeah, pretty much that simple. Start, scripting block, stop.

Scripting!

Now for the awesomesauce that makes this work:

var datastore_mgr = Host.configManager.datastoreSystem;
 
var new_spec = new VcHostNasVolumeSpec();
new_spec.accessMode=VcHostMountMode._readWrite;
new_spec.localPath=DatastoreName;
new_spec.remoteHost=remoteHost;
new_spec.remotePath=remotePath;
new_spec.type=”nfs”;

try {
    var newDatastore=datastore_mgr.createNasDatastore(new_spec);
}

catch (ex) {
    System.log ( ex + ” creating datastore ” + remoteHost + “:” + remotePath + ” on ” + Host.name + ” as datastore ” + DatastoreName );
}

Note: Parts of this script were borrowed from the VMware communities here. Also found this here.

Running:

Results:

Summary

So, the workflow itself is kinda useful for a single host, it becomes more powerful when you embed it within another workflow to do say all hosts in a cluster. However, that’s an activity for the reader.

Download

The workflow can be downloaded from here!

More Info

We’ve talked about vCO extensively in the past… you can find some additional info here.

We’ll skip the reason you need tools installed. We’ll also skip a bit on the other ways to do this in PowerCLI. Rather, we’ll bring you a way to do this in Orchestrator.

Note:

If you’re not using vCO, you should be. Why? I covered that here. Additionally, there are some excellent vCO resources here.

VMware Tools Workflows

vCO ships with four workflows for managing VMware tools:

• Mount tools installer
• Unmount tools installer
• Upgrade VMware tools
• Upgrade VMware tools at next reboot

All of these are found in the vCenter library of workflows that rolls with the vCenter plug-in. Specifically they’re found under “Library > vCenter > Virtual machine management > VMware Tools”

Mount/Unmount tools installer

These two workflows take a single VM as input and can be used when provisioning a new VM. In the case of Unmount, they are also useful in ensuring a VM does not have the tools installer mounted before a VMotion. The real power with these two comes in your ability to use them as a part of a larger workflow however.

The mount and unmount workflows both have identical schema and an identical amount of code in their scripting blocks. Let’s take a look at each:

Schema

Code

vm.mountToolsInstaller();

vm.unmountToolsInstaller();

A bigger workflow

Well, I said the power in this was when you wanted to do more than a handful of VMs right, so here’s the bigger workflow promised:

Lots of little cross-wise lines, etc. Working around the workflow:

• Get a list of everything
• Make sure we have VMs left to parse
• Set the active VM
• Is it powered on?
  • If not, increase the count, start from step 2
  • If yes, should we mount or unmount the tools?
    • If yes, mount em, continue
    • If no, unmount the tools and continue

Confused? Well, I’ll spare the additional code as you can likely figure it out, and have uploaded the completed workflow here.

Upgrade Tools (on next reboot)

The next two in our list are the upgrade tools workflows which more or less function like their PowerCLI counterparts mentioned above. The first has a really really simple schema, so we’ll skip it. The more interesting one is “on next reboot”:

Of this, the more curious part is what’s going on behind the “Upgrade Tools” bit:

if (vm.summary.guest.toolsVersionStatus != “guestToolsNeedUpgrade”) {
    System.log(“Tools do not require upgrade for vm: ” + vm.name);
}
else {
    System.log(“Upgrading tools for vm: ” + vm.name);
    task = System.getModule(“com.vmware.library.vc.vm.tools”).upgradeToolsAtNextReboot(vm);
}

Do I need an upgrade? OMG Yes I do, send a call to the vCenter API to upgrade the tools at next reboot. Or so. This too could be worked into a larger workflow like we did before. That said I’ll leave it as an exercise for the end user this time.

Summary

Is vCO awesome? You bet! This time around we mounted and unmounted your VMware tools, and set the tools to upgrade at the next VM reboot, you know, in case you don’t have a maintenance window.

As always, if you have any questions drop a line in the comments or hit me up on twitter here.

As mentioned here, I have been playing around with the “nuke from orbit” bits in vCO for both Virtual Machines & their AD objects. One of the snags I hit was the fact that one of these things was not like the other. That is, the VC:VirtualMachine bits that the vCenter plug-in uses could not be passed directly to the AD:ComputerAD that the Active Directory plug-in uses.

Translation from VC:VirtualMachine to AD:ComputerAD

So to go from one to the other we need to use the getComputer method from the ActiveDirectory scripting class (from the plug-in) and call it using the name of the VM we’re working with:

computer = ActiveDirectory.getComputer(VM.name);
System.log (computer);

Wait, what?

Yeah, trying to explain that in a way that was non-programmer speak can get be interesting. Basically, we’ve got a foreign and domestic car and need to have a way for the mechanic to be able to work on both. So what we did was give him a set of tools and manuals to make the conversion. I think…

Why is this important?

For the AD use case it’s pretty important that you be able to target the right object if you are going to be deleting it from AD. If you are beginning with a VM, you’ll need to know how to find that VM in different systems. On a grander scale, being able to talk about the same thing between several systems is critical.

Picture credit to this guy.

This week has me finishing up Chapter 10 or so of the upcoming vCO Book (Amazon pre-order link here). Chapter 10 is the “How to cleanse a VM with fire” or so, and one of the varied bits of clean-up you have to do after deleting a VM is to pop that sucker out of your AD. Afterall, you don’t want to have stale machine accounts sitting around do you? That’s almost as bad as the stale pizza left on your table… no good.

Getting the vCO AD Plug-in

Point your favorite browser here, and select “plug-ins”:

Installing the vCO AD Plug-in

After you’ve logged in and pulled the 11MB worth of plugin down, you’ll want to log into your vCO Configuration interface and go to the plug-in’s area to upload it:

Those with a keen eye will notice I’ve already got it installed. You’ll need to restart the vCO server service to complete the installation.

Configuring vCO AD Plugin

Thankfully the homelab is small enough that the “Copy from LDAP” bits works pretty well. Your mileage will vary:

Workflows in the AD Plugin

Now, take a gander at some of the new things exposed in your vCO client:

There are a few more than that also.