CLI

Here in Virtualization Short Take #11, I offer to you a collection of virtualization-related news and tidbits and my thoughts on them.

• I seem to be on a bit of kick reading Ryan Arneson’s stuff these days. This time is actually an older post of Ryan’s on using the COMSTAR stuff from Sun with ESX. It’s an interesting read. I’m quite fascinated by the myriad things that Sun is doing with storage, and I hope that some of these actually get backed with good execution. I’ve guess I’ve heard the saying “Sun is where storage goes to die” from too many Sun veterans.
• I was notified of this post by Chris Barclay of Virtual Iron regarding a comparison of Virtual Iron Virtualization Manager and Citrix XenCenter. This is an interesting comparison considering that both products are built on the same underlying hypervisor (Xen). In this case, Chris makes the argument that management is the piece that sets one virtualization solution apart from other solutions, and that in this particular case Virtual Iron’s management capabilities far exceeds those provided by XenCenter. I don’t have any direct experience with either of these products, so I can’t attest as to the accuracy of his claims. While I don’t necessarily agree that the hypervisor is being commoditized, I do agree that management is increasingly becoming the factor that distinguishes solutions. In this regard Microsoft has an early lead, in my opinion, with cross-platform VM management inside Virtual Machine Manager 2008. Will other vendors follow suit?
• Last week the new VMware Networking blog posted a notice about a new whitepaper jointly authored by VMware and Cisco. Duncan over at Yellow Bricks also picked this up, but from a different source; the whitepaper, however, appears to be the same from both sources. I haven’t had the opportunity to fully review it yet, but I do plan to do so and will highlight any notable recommendations here.
• Chad Sakac, the “VMware Guru” for EMC, published an entry on stretched ESX clusters. This article was picked up by a number of other bloggers (here or here, for example), so I won’t rehash it all here again. The timing on the article was helpful; he wrote that and not more than two days later I had a customer asking about doing this very thing. Personally, I agree with Chad that it’s generally a bad idea, and so it was handy to be able to point the customer to this article as further support. One other thing I did get out of Chad’s post—how many of you picked up that up to 10 different isolation addresses can be configured? Is that in the documentation somewhere and I just missed it?
• Continuing on with Chad, it appears that an old VMware HA article of mine is useful in helping to understand how the VMware HA admittance algorithm works. Chad’s article provides excellent details on the key concepts to understand.
• Most readers have probably seen the article describing how to access the ESXi command line. This article also shows you how to enable SSH access to that CLI. I found this information so handy that I added it to my del.icio.us bookmarks. As ESXi gains broader adoption, this kind of stuff will be very useful.
• With the release of Hyper-V, comparisons of Hyper-V vs. ESX will become much, much more common. Here’s another one for review as well. I’ll echo the comments in this article regarding the comparisons: it’s not about the brand, or the technology, it’s about the solution.
• I’ll have to partially disagree with the sentiment behind this article regarding the use of virtualization as a DR tool. The article intends to present 5 things that should be considered when using virtualization for DR, but does not, IMHO, accurately present some of the challenges around virtualization for DR. How are the VMs being replicated over to the DR site? Replication technologies need to be properly coordinated with the virtualization software so that the data being replicated is consistent and useable. If this is synchronous replication it’s not as much of an issue, but it’s definitely an issue with asynchronous replication. What about registering VMs on the DR site? How does one handle VirtualCenter in this kind of scenario? Is testing failover really that easy? My experience indicates that while virtualization can certainly assist in creating a good DR plan, it’s only one part of an overall DR solution, and it can create its own unique challenges. Again, the timing of this is interesting; I just came across the article after finishing up a presentation about the use of virtualization in disaster recovery solutions.
• Anyone working in the VDI environment has almost certainly had more than their fair share of discussions about remote display protocols. This article on x86virtualization.com provides a decent overview of VNC, RDP, ICA, and Net2Display. Seems like I recall seeing something somewhere about VMware assisting in the development of Net2Display; anyone know anything more about that?

I guess that about does it for this round. Thanks for reading, and feel free to share your thoughts in the comments.

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?