The upshot is that if you pre-configure Linux and Windows Server VMs (we tested Windows 2008 R2 and Windows 2012 gold release), you can envelop them in what amounts to a virtual wrapper that isolates them (largely) from machine-specific settings. This means that ISOs can conceptually be "hatched" into instances that are "wrapped" with settings that allow them to be moved and manipulated more as true virtualized object instances than was possible before.
Hosts still need vMotion or Storage vMotion (the new secret sauce) to permit live migration across hardware. But VM instances become more atomic, keeping their functionality intact and are nearly immune to their external hosting environment's characteristics or even geography. They live in isolation, doing their work, and while they aren't ignorant of their external settings, the settings are a convenience -- they're plugged into sockets, very "The Matrix"-like.
Once we accessed a vSphere 5.1 host, our vSphere 5.0 client was updated automatically, and didn't give us much of a choice about the location of where the new vSphere client was going to reside, an installer inflexibility. Nonetheless, we installed the new client and obtained access immediately to our host VM platforms.
It's probably best at this point to install the vCenter Server Appliance (vCSA) locally to allow it to access resources remotely. Missing this step caused us delays.
Using vSphere 5.1 client, we wanted to deploy an OVF template that installs the VMware vCenter 5.1 Server Appliance (VCSA). The server appliance also holds the optional web UI, and is a management control center for vS51 installations. The VCSA uses a template file (OVA and OVF files that describe the procedure), and two VMware Virtual Disks (VMDK) -- four separate files in total.
The OVA/OVF template files execute and deploy from the client-local resources including http/https/ftp and local disks/shares. We used an NFS share controlled by our newly updated vSphere 5.1 client in the lab. The NFS files are about 70 miles away.
This was a mistake on our part, as the vSphere 5.1 client initially dragged the .OVF, .OVA, and the two VMDK files associated with the vSphere Server Appliance out of our NOC cabinet servers, across the Internet to the lab, where it dutifully then sent them back across the Internet to the target ESXi 5 host that we'd just brought up. The vCenter 5.1 client warned us: 149 minutes remaining; in reality, it took longer, about three hours. Locally, it would have taken perhaps a half hour.
This misery is obviated if one installs the Server Appliance locally. Remote execution would have been more handy, but as the VCSA does this, it has to be installed first.