This week the APAC BrownBags covered VCAP-DCD and vSphere Host Design.

Video

Slides

In looking around vCO, at least in the default plug-in, there was not a good variety of workflows for configuring hosts. This workflow, will set the NTP server on a host.

Schema

Not a very creative schema, and for good reason. Also note, it is designed to work on a single host at a time. If you want to do all hosts, you can include this workflow inside a larger one to process a number of hosts:

This workflow has only a single input of type Vc:HostSystem and a single attribute, a string, for the NTP server.

Code

This is where things get a bit interesting. Using Onyx I was able to capture the basics of the JavaScript. I then beat my head against the wall getting it translated. Thanks to Joerg Lew of vcoportal.de I got the last bits I needed to make it successful:

// ——- UpdateDateTimeConfig ——-
var config = new VcHostDateTimeConfig();
config.timeZone = “UTC”;
config.ntpConfig = new VcHostNtpConfig();
var ntpServerArray = new Array()
ntpServerArray.push(ntpServer);
config.ntpConfig.server = ntpServerArray;
config.ntpConfig.server[0] = ntpServer;

// ——- Update Config ——-
var dts = VMHost.configManager.dateTimeSystem;
dts.updateDateTimeConfig(config);

// ——- EnableRuleset ——-
var ruleset = VMHost.configManager.firewallSystem;
ruleset.enableRuleset(“ntpClient”);

// ——- UpdateServicePolicy ——-
var serviceSystem = VMHost.configManager.serviceSystem;
serviceSystem.updateServicePolicy(“ntpd”, “automatic”);  // HostServiceSystem

// ——- StartService ——-
serviceSystem.startService(“ntpd”);  // HostServiceSystem

The first block builds the configuration that gets sent along to the host. The second block actually sends said configuration (also, it’s where I threw some derp on using nested managed objects… suffice it to say, it works now and JavaScript is not PowerCLI). The third set enables the NTP Client in the ESXi firewall. The fourth and fifth blocks handle setting NTP to start with the host and turning it on now.

In Action

There aren’t many exciting ways to show a workflow in action and using screenshots always feels like those cooking shows “baked at 450 for 3 hours” or so. But, here it goes:

Running:

Host Before:

Host After:

Download

This workflow can be pulled down from here. If you have any questions, comments, enhancements, etc. Drop me a line.

This is a revisit of an older post on running ESX4.x in Fusion 3.x. This time updated for ESXi 5.x and Fusion 4.x. The steps this time around are nearly identical to the ones last time:

1. Pull down the ISO
   
2. New VM
   
3. Point the installer at the ESXi ISO:
   
4. Confirm the OS Type:
   
5. Wait a bit… then awesome:
   

There you go. If you liked this, then you should follow me on 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.

So this happened. VMware has pulled the ESX Classic binaries from being available as a direct download:

While they do provide a download link for ESX classic, it sends a pretty clear message… If you haven’t made migration plans, NOW is the time to do so.

Thankfully, they’ve not left folks completely out to dry and have provided some basic ESXi migration guidance here.

Additionally, I’d suggest as a first step, installing ESXi as a VM inside VMware Fusion or Workstation to become familiar with it before migrating your production hosts. Like using Fusion/Workstation for other test/dev workloads, this should be no different. Test your tools, agents, processes, etc against the VM image before blowing away a production host.

Amazon posted my 4 star review of Ed Haletky’s (@Texiwill) updated VMware ESX and ESXi in the Enterprise.

Let me start with saying I’ve read the first edition of this book and Ed’s Security book and found both to be excellent.

As this book was a second edition, I focused my reading on those updated areas and there were a few. As always Ed provided a good balance between detail and real world examples/implementations that carry the weight of his experience with VMware on the whole.

I’d recommend this book for those getting into their first few ESX/ESXi implementations, and to supplement the official VMware courseware with real world examples.

All and all a good volume to get yourself going with some real world ESXi/vSphere implementation.

The TSM in ESXi is a Posix like environment and much of it resembles and behaves much as you would expect the old RHEL based service console to. That said, some of it is very different too. Today, I figured out that while it may not have all of the features I’m used to (screen), it does have some useful multi-task from single console functions. That is, it has “Jobs” support.

Jobs Support?

Each task you execute on the CLI is a “job” for the system. Most times these will be fairly quick, ls, esxtop, esxcfg-something, and such. However, if like me you are attempting to move a relatively large set of files from the CLI, and still want to use the system for other things… that’s where jobs come in.

Basic Job Management

• Ctrl + Z – Suspend a task
• bg – execute the last suspended task in the background
• fg – bring the last task back to the foreground
• jobs – lists running jobs & job id
• bg/fg $jobid – Same as above, $jobid is specified when you have multiple jobs going

Example

/vmfs/volumes/4cb08ee3-9aabb1c8-c722-002170bd4485 # mv ./* /vmfs/volumes/ix4-200d-nfs/ -f
[1] + Stopped (signal)           mv ./* /vmfs/volumes/ix4-200d-nfs/ -f
/vmfs/volumes/4cb08ee3-9aabb1c8-c722-002170bd4485 # bg
[1] mv ./* /vmfs/volumes/ix4-200d-nfs/ -f

/vmfs/volumes/4cb08ee3-9aabb1c8-c722-002170bd4485 # jobs
[1] + Running                    mv ./* /vmfs/volumes/ix4-200d-nfs/ -f

What you’re looking at in the above example, is my executing the move command, then suspending it (“Stopped”). Next I execute bg to get the task running again in the background. Finally you see where I launch “jobs” to get the status.

Summary

Normally you’d not be running day-to-day ops from the ESXi TSM, it’s nice to have jobs support handy when you need to do some heavy lifting.

As a side note… I wonder how much spam I’ll bring in by mentioning vSphere and Jobs in the same post. Photo by this guy.

Following up on some of my other TIL posts and a really really bad “vMotion on a stick” experiment, I had to get down and dirty with the ESXi CLI. Without further adieu heres how to List, Start, and Stop VMs from the ESXi CLI (aka TSM):

Note:

You’ll need to have TSM (ssh) enabled on your ESXi host for this to work.

List ESXi VMs

~ # vim-cmd vmsvc/getallvms
Vmid            Name                                          File                                      Guest OS          Version   Annotation
1      dc01.provmware.com        [ix4-200-iscsi] dc01.provmware.com/dc01.provmware.com.vmx        windows7Server64Guest   vmx-07             
2      vCenter01.provmware.com   [ix4-200-iscsi] vCenter01.provmware.com/vcdb.provmware.com.vmx   windows7Server64Guest   vmx-07             
3      vcdb.provmware.com        [ix4-200-iscsi] vcdb.provmware.com/vcdb.provmware.com.vmx        windows7Server64Guest   vmx-07

Stop VMs

~ # vim-cmd vmsvc/power.off 3
Powering off VM:

~ # vim-cmd vmsvc/power.getstate 3
Retrieved runtime info
Powered off

Start VMs

~ # vim-cmd vmsvc/power.on 3
Powering on VM:

Perhaps it’s just been a while since I’ve needed said floppy image, but I recall a time when you had to search the VMware KB to get the XP LSI driver. Well, today while changing some of my lab VMs over to PVSCSI, I found that the needed floppy images are in “/vmimages/floppies/” (at least on my ESXi 4.1 test system).

Take a look:

We’ve covered snapshots here a few separate times in past. However most of these were focused on ESX classic or preforming the work using one API or another. As VMware is making the shift to ESXi, it makes sense that you will need a way to deal with snapshots from the ESXi console (aka TSM/Tech Support Mode).

Process

List All VMs

You’ll need this step to identify the Vmid of the VM you want to work with. Note in all commands that follow, 16 is the VMID. You’ll need to change that for your situation.

~ # vim-cmd vmsvc/getallvms
Vmid        Name                                  File                              Guest OS     Version   Annotation
16     ProVMware Test   [datastore1] New Virtual Machine/New Virtual Machine.vmx   ubuntuGuest   vmx-07             

Create a Snapshot

~ # vim-cmd vmsvc/snapshot.create 16 TestSnap
Create Snapshot:

List all Snapshots

~ # vim-cmd vmsvc/snapshot.get 16
Get Snapshot:
|-ROOT
–Snapshot Name        : TestSnap
–Snapshot Desciption  :
–Snapshot Created On  : 1/25/2011 10:29:9
–Snapshot State       : powered off

Remove the Snapshot

~ # vim-cmd vmsvc/snapshot.removeall 16
Remove All Snapshots:

Resources/References

• vim-cmd (http://www.yellow-bricks.com/2008/08/21/esxi-and-ssh-whats-next/)
• vi-toolkit (http://www.vi-toolkit.com/wiki/index.php/Vmware-vim-cmd)
• VMware KB (http://kb.vmware.com/kb/1026380)

Summary

The concepts behind snapshots still apply (deleting big ones sucks, etc), but now you know how to handle them from the ESXi TSM also.