Where are the commands that mirror esxcfg-* and vicfg-*? This solution seems incomplete without the same remote CLI commands in PowerShell are in the Perl based CLI.
It is possible to install the VI Remote CLI and the VI Toolkit (for Windows) on the same system. If you install the VI Remote CLI you can invoke the esxcfg-* and vicfg-* commands from PowerShell. For this reason we're not looking at implementing equivalent functionality using cmdlets in the first release.
Ok, so I was wrong, I can admit it. I had an improper understanding of what you were referring to. So now we're back to two toolsets. What happened, Carter? Did the timing not work out right?
Nah, no problem. I know or realize they are really gearing up to support PowerShell extensively! But like everyone else in the IT industry, we just can not seem to get stuff fast enough. Windows oriented support teams, those that I deal with, hate the half perl, half PowerShell situation that exists right now.
Believe it or not, I had a client as me today... maybe the 20th or 25th time I have heard the same basic question since 3i installable release... "So, what is VMware's problem, can't they get 3i out the door as a complete solution?" The specific client was referencing the lack of 3i/VC integration to enteprise monitoring frameworks, like HP openview, CA-Unicenter, Tivoli ITM/TEC/TBSM, MOM, etc.
We just can't win some times!
I'm a bit confused by what you're saying so I want to make sure we're all talking about the same things.
Today we have the RCLI, which gives you esxcfg-* and vicfg-* commands that you can run against remote VC and ESX installs. The RCLI uses Perl, but you don't have to interact with Perl directly when using these commands. These commands are useful for setting up things like storage and network, among other things.
In the PowerShell technology preview we're all currently using, your ability to configure VC and ESX hosts using cmdlets is very limited. This is our #1 focus area for the Beta we will be releasing in 2008, and will likely continue to be a focus area as we move to a generally available release. In other words, we will be adding cmdlets that allow you to do the sorts of things you can do with esxcfg-*, but they will be implemented as cmdlets, so the obviously won't use the same names, syntax, parameters, etc. Schorschi is right to say that we just can't get this stuff out fast enough, not that this is going to stop us from trying :smileycool:
So if what you really want is the esxcfg commands you have today, with the same commands and parameters, you should use the RCLI. If you want cmdlets, you will have to wait a bit, but we think that in the end, the cmdlets will be a lot more powerful and much easier to use. Of course you can do host configuration today using the PowerShell toolkit, using the approach I outline in this thread, but doing that is not as easy as it will be using cmdlets.
I hope that helps clear up some confusion (including my own.)
Commands in Window PowerShell CLI should mirror RCLI functions, implemented as cmdlets is fine. Providing the functionality is identical. For example esxcfg-mpath -l as cmdlet, say get-storage-paths, or whatever. I am not concerned with naming nor identical parameters, but the information returned, or the settings possible to be set should be identical in concept and context.
One place in which I don't mind things being 'identical in concept and context' vary from the web services API (don't know the RCLI at all) is the host auto power on / power off settings. I know that it's a host configuration in the API, but I want it to be a guest configuration. I think it makes more sense to have a property on the VM objects for this particular setting.