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.

While this isn’t as big a problem as it used to be, Context Switches in applications can still bring a VM to it’s knees. In this post I’m going to link you to some resources as to what context switching is, how to look for it, and why excessive context switches hurts performance.

What Is Context Switching

• Wikipedia’s answer here.
• Linfo’s answer here.
• How they work on Windows.
• Seemingly, “Windows Internals 5th Ed” has some info in Chapter 5: “Processes, Threads and Jobs.”

Monitoring Context Switching

• On Windows – here and here.
• On Linux, you can use SAR:
• sar -w (more here)
• More on the Perfmon counters here.
• Page Faults (They cause context switches) on Windows here.

Why Excessive Context Switching Sucks

This, is likely the best post I’ve read on the cost of a context switch. Tsuna (the fellow from the first post) links to an excellent paper on some of the indirect costs also (here).

Virtualization
I was wondering how much overhead there is when using virtualization. I repeated the benchmarks for the dual E5440, once a normal Linux install, once while running the same install inside VMware ESX Server. The result is that, on average, it’s 2.5x to 3x more expensive to do a context switch when using virtualization. My guess is that this is due to the fact that the guest OS can’t update the page table itself, so when it attempts to change it, the hypervisor intervenes, which causes an extra 2 context switches (one to get inside the hypervisor, one to get out, back to the guest OS).

This probably explains why Intel added the EPT (Extended Page Table) on the Nehalem, since it enables the guest OS to modify its own page table without help of the hypervisor, and the CPU is able to do the end-to-end memory address translation on its own, entirely in hardware (virtual address to "guest-physical" address to physical address).

This bit, is important to note… newer generation processors (those with NPT) should not suffer the 2-3x increase in cost. However, they’re still expensive.

As always, if you’ve additional questions, please drop a note in the comments, or hit me up on Twitter.

The Problem!

Was doing some work with UDA and nested ESX & ESXi installs this weekend and ran into an interesting hiccup:

Or on ESXi:

What? Can’t format what? But we’re working with nested ESX, it’s a VMDK, format it! I tried any number of things here: Different controller types, disk sizes, partitioning within the kickstart file, etc. Nothing seemed to work. That is until I fired up Twitter and got a hint on the right direction from @hyperviz0r (http://www.hypervisor.fr/). He indicated that my problem may be related to NFS.

The Answer!

Sure enough, after some searching on the VMware forums, there are others out there with this problem. All of it seemingly related to nested ESX on NFS. I changed the build over to local storage on the ESX host and the install finished. I was also able to test successfully using iSCSI. I don’t have much in the way of explanation however, just that using another storage medium seems to work well.

You should follow me on twitter here. Or, leave a comment on the post!