Along with the release of VMware Infrastructure 3 version 3.5 and ESX Server 3i version 3.5, VMware released the VMware Remote CLI. This was supposed to be, to my understanding, the new way to manage ESX Server 3i since there is no longer a Service Console with ESX Server 3i. Of course, you can still manage ESX Server 3i with VirtualCenter, but the Remote CLI was the only reasonable way to get a command line interface. In addition, the Remote CLI is the method whereby users can initiate a Storage VMotion operation.
Given the relative importance of the Remote CLI, I expected more. After visiting the download page for the Remote CLI and seeing, once again, only Windows and Linux versions, I downloaded the Remote CLI appliance. It seemed logical to me that I should be able to import the virtual appliance into my DRS/HA cluster and simply run it from there.
Unfortunately, things didn’t work quite as I had planned. Despite repeated attempts, the import of the virtual appliance from the *.OVF file into VirtualCenter continually failed when attempting to map the networks for the virtual appliance. No amount of fiddling with the *.OVF file to put in network names that I was currently using would fix the problem. If anyone has a workaround for this particular issue, I’d love to hear it.
Seeing that the virtual appliance was apparently a dead end, I proceeded to install the Remote CLI on my VirtualCenter server. When the installation was complete, I found that I had no visible way of even knowing if the installation was successful. No new icons, no Start Menu items, no pop-up dialog box asking me if I’d like to run the Remote CLI…nothing. Only by opening a command prompt and navigating to the directory where the Remote CLI had been installed was I able to determine that something had actually happened. And what had happened? VMware had installed ActivePerl and a set of Perl scripts. That’s all.
I did recall seeing this warning from Bob Plankers about logging out and logging back in again, so I did that. It didn’t really make any difference. I can run Remote CLI commands without having to specify the path, but I do have to specify the “.pl” extension on everything. And the scripts seem slow, although that may be attributable to the slightly older hardware I have in my lab.
Something about all this just seems really unpolished. Unfinished. Rushed. Pick whatever adjective suits you best here; I just know that this was not what I had expected. Why call it the “Remote CLI” if its really just a collection of scripts that operate remotely? Wouldn’t “ESX Server 3i Management Tools” be better? And yes, perhaps I am being a bit picky, but sometimes it’s the little things that can make or break a customer’s first impression. Would you want your customer’s first impression of VMware’s products to be the Remote CLI?
Tags: CLI, ESX, ESXi, Virtualization, VMware
-
Yeah, the RCLI appliance leaves even more to be desired, had you been able to get it running. As you put it, the relative importance of the RCLI means I’m not going to 3i anytime soon. Cool concept, needs implementation work.
For now I can tolerate using the svmotion.pl script, but that’s about it.
-
Would there be interest in being able to get to the command line of any GUESST OS as well as non-Virutalized servers with the same tool?
If so, our product allows access to each GUEST OS on the VM as well as to non-Virtualized servers. The access is via VNC/RDP or via command line. Our product runs on “virtually” (
) all platforms and allows access to all platforms.Please let me know if there is an interest as we are looking for folks to try our product.
-
Jim,
I appreciate the offer, as I’m sure my readers do, but I generally prefer substantive discussion as opposed to blatant advertising.
Now, if your product will assist in the management of ESX 3i and performing Storage VMotion operations, then please speak up. Thanks!
-
I wanted to make sure that gaining access to the command line was needed as well as access to non-VM targets that allow network or emergency/out of band access. Please excuse, in advance, my rather lengthy reply!
We provide a service daemon called emser. This daemon was written to run on console servers and host operating systems. An emser overview is included at the bottom of the post.
We also provide access to the GUEST OS via VNC, RDP, ssh and telnet.
[Note from Scott: I snipped the rest of Jim's _very_ lengthy post, as it was primarily marketing information about his organization's products.]
-
I was similarly unimpressed by the RCLI. Have you checked out the VI PowerShell Toolkit yet? Read up on it at their blog (http://blogs.vmware.com/vipowershell/). There is a closed beta on now, open beta beginning sometime soon. I’m having a lot of fun using it. It beats perl any day, however I don’t know if it supports vmotion stuff yet. VMware will continue to support Perl for the Linux crowd, but the Windows guys out there will be very pleased with what VMware is working on.
-
I ended up on your site for the exact same reason… I couldn’t find where the VMware Infrastructure Remote CLI had been installed, except for the perl crap that got installed…
More than disappointed I’m actually very unhappy.
-
My disappointment is with VMWare Marketing. VMWare pitched ESXi as an improvement (if not equal) to ESX. While ESXi is doing a fine job of hosting VMs, I have spent a lot of time searching for practical tools to take regular backups of entire VMs. Seems the best tools depend on having a Service Console, and there seems to be nothing that will compress flat vmdk files prior to sending them off towards backup media. If however, VMWare had Marketed ESXi as Trial-Ware, I would be quite pleased with the performance of ESXi.
Site Sponsors
7 comments
Comments feed for this article
Trackback link: http://blog.scottlowe.org/2008/01/07/underwhelmed-by-the-remote-cli/trackback/