Let me address some of these points.
vCLI and PowerCLI are both tools that we plan to support going forward. If you compare these tools there are a lot of data points that show that PowerCLI has a lot more interest and momentum around it than vCLI. We're going to build on this momentum, I think that when you see PowerCLI 4.0 U1 you will be amazed at all the new capabilities we've added. PowerCLI is not going away, it will continue to improve.
On the other hand, you may have noticed that both Cisco and EMC use the vCLI to get their software components installed into ESX. This is because vCLI has built-in patching capabilities, something that PowerCLI lacks. Because of this and other reasons, vCLI is not going anywhere.
To another point, we didn't forget to implement esxcfg-* in PowerCLI. PowerCLI has a different model, approach and philosophy, and we don't plan to implement these commands. Instead we are implementing PowerShell equivalents and in many cases the functionality is already there.
As for CIM, the reason we have been discussing CIM is because people need to get hardware serial numbers and they are not available in the vSphere API. The real bug here is with the vSphere API not having this important information. Generally speaking I wouldn't recommend going directly to CIM unless you really need to. If you really do need to there is a supported choice on Windows: winrm. It is not as clean as the method I detail in my blog but it works and is supported. Longer term you can expect that we will abstract this stuff into cmdlets, but today we lack a firm foundation to build upon (specifically we are waiting for PowerShell 2 to become available and adopted.)
I would say there are two ways that a PowerCLI-only approach is not practical today:
1. Scripting patch deployment or deploying Cisco Nexus 1kV or EMC PowerPath/VE is only supported with vCLI. In the latter case this is based on the documentation that comes directly from Cisco/EMC. This situation will be improved as we add patch capabilities to PowerCLI, but a real, supported PowerCLI-based approach will not arrive in 2009.
2. Troubleshooting with resxtop is only possible with vCLI (and in turn this is only possible on Linux vCLI, not Windows). This problem is more difficult because the data resxtop uses is not available in any public API, and the solution is probably a few years out.
So if you need to do these things, a PowerCLI-only solution is not going to work for you, you will need to have vCLI available to some degree. If you need to transition scripts based on esxcfg-*, you may find it easier to transition to vCLI rather than PowerCLI. For other cases I wouldn't hesitate to say that PowerCLI is your best bet.
=====
Carter Shanklin
Read the PowerCLI Blog
[Follow me on Twitter|http://twitter.com/cshanklin]
