Share on Facebook0Share on Google+0Share on LinkedIn0Share on Reddit13Tweet about this on Twitter0

A Command Line Interface (CLI) allows users to write commands or scripts in a console or (remote) terminal. Commands respond with a text-based representation. Some example in the vSphere environments, are the commands executed with the ESXi shell or thought the ESXi SSH service. But also, all the scripting languages are another example of CLI, like, for example, PowerCLI.

Note it’s also possible build semi-graphical user interfaces, for example in ESXi consider the Direct Console UI (DCUI).

A Graphic User Interface (GUI) is a graphical representation in which the users can interact with software or devices through graphical objects, like windows, buttons, scrollbars, icons, using a graphical display and a mouse (or a touch device), or also using remote graphical protocols (like RDP or X-Window).

Usually, it is an easy-to-use interface good for novice users, because it’s intuitive, easy to learn and reduces cognitive load. But can be good also for users that need to do simple tasks or needs high-level information.

Typical GUI interfaces can be based on specific graphical programs in the form of a “thick” programs (for example the legacy vSphere Client for Windows based on C#), or based on a web application (for example the vSphere Web Client or the new HTML5 vSphere Client).

CLI vs. GUI for VMware Admins

In several cases, a user can choose to use the CLI or GUI, in other cases, for example for some specific tasks, maybe it’s possible to use only one type of interface.

Also note that there are other types of interfaces like the API, but in this case, we cannot really consider a user interface. And sometimes the boundary it’s not so clear and easy to be defined, for example, several admins use the RESTful API not as a development tools, but much like as an automation tool, instead of CLI (or complementary to CLI).

StarWind HyperConverged Appliance is a turnkey, entirely software-defined hyperconverged platform purpose-built for intensive virtualization workloads. Bringing the desired performance and reducing downtime, the solution can be deployed by organizations with limited budgets and IT team resources. Also, it requires only one onsite node to deliver HA for your applications that make the solution even more cost-efficient.
Find out more about ➡  StarWind HyperConverged Appliance

But what are the differences between the two approaches and which are the pro and the cons of each of them?

The following table illustrates which interface has the advantage in certain categories and why:

Topic CLI GUI
Ease to use To be productive you need a good knowledge and familiarity with commands and their syntax. GUI is much more visually and could be intuitive, for this reason, could be simple for new users or novice uses.

With the GUI it’s possible also implement wizard to make specific task much easier and assisted.

Speed of execution If you already know the right command and syntax, CLI could be really fast to be executed. Also if you know the right position on the menu tree, probably you need to access multiple level and click several times before complete a task. Wizard-based task can improve the usability, but makes the entire process much slower, due the multiple iterations.
Repeatable CLI is repeatable and permit multiple executions, for example, to make the same tasks on more systems. To repeat the same task using the GUI you need to navigate the same menu and repeat the same operations multiple time.
Language CLI can used both as a language or as a documentation. Also usually it does not depends by the different localizations. GUI aspects can vary, for example, due to localization.

GUI tasks can be documented with snapshots, but it’s less effective than using CLI commands.

Remote management Remote text-based protocols, like SSH, could be very bandwidth effective. Remote graphical based protocols, like RDP or ICA, require usually more bandwidth.

Web-based application can be more bandwidth “friendly”.

Portability and multi-platform CLI could be multi-platform depending on if you have the remote terminal client or the right interpreter for multiple systems. Thick graphical based applications usually are not multi-platform, unless they are executed remotely. Web-based application, by design, could be more cross-platform.
Control CLI provide a good control on what it’s executed (if you know how execute it). GUI can better assist and drive the user.
Completeness Depending by the solutions, in some cases the GUI may call the CLI commands that is much complete. Depending by the solutions, the GUI and the CLI may be complementary.

But the GUI can become a single pane of glass.

Resources Usually the command line tools require less system resources than GUI. A full GUI client may require more system resources because of the elements that require loading, such as icons and fonts. Also, a web-based application may consume more resources compared to CLI.
Requirements CLI just requires a keyboard and a “terminal” (local or remote) access. GUI requires keyboard and mouse and a graphical device.
Accuracy CLI is more accurate and precise, just because command behaviour is usually predictable.

But of course, mistyping could result in complete chaos.

GUI may have strange behaviours, for example in web interfaces sometimes a page refresh could be needed.
Scripting and automation Using CLI is easy build script and automate process. Most CLI are just extension of scripting languages. Creating scripts using a GUI maybe be simple, depending by the automation level provided by the GUI. But it most cases there is nothing.
Diversity and consistency CLI is usually much “stable” during the years. Also, if a new command may be introduced, the original command almost always remain. GUI may change due to technology changes of new user devices.

Now let’s descent all those aspects to the specific case of VMware vSphere, using those examples:

  • For CLI: I just consider the local CLI (ESXi and VCSA shells) and PowerCLI, but of course, there are several others possible CLI, including the vMA and different other scripting languages extensions.
  • For GUI: I consider mostly the web clients, but for vSphere versions previous 6.5 there are still some people that are using the legacy vSphere Client for Windows.
Topic CLI GUI
Ease to use CLI initially it’s not easy, but more you are using it more become easiest.

For PowerCLI there is also the difficult to know the language itself, to better be productive.

All vSphere web interfaces are intuitive, especially for new users or novice uses.

Also, the different wizards and helps (like the getting started page) may help you to do your first steps.

Speed of execution CLI is quite fast. Also for PowerCLI, after that PowerShell has been loaded, the execution is fast. The promise of the vSphere web was to be more faster than the legacy vSphere Client, but for small environment it’s not so true.

And compared to CLI executions, it’s usually slower.

Repeatable CLI is repeatable and permit multiple executions, for example, to make the same tasks on more systems. To repeat the same task using the GUI you need to navigate the same menu, and repeat the same operations multiple time.

At least, for failed task, with the web clients is possible resume them easily.

Language CLI can used both as a language or as a documentation tool. It’s repeatable but also consistent across different vSphere version (at least starting from v5). The UI vary too much across the different web client (and also compared with the old legacy client).

GUI tasks can be documented with snapshots, but it’s less effective than using CLI commands.

Remote management Using SSH you can access the ESXi or the VCSA shell. But you can use other solutions like the RCLI.

Or better use PowerCLI that can manage a remote vSphere environment.

Both the web and the legacy vSphere clients are designed for the remote management, but latency (and bandwidth) may limit their usage.
Portability and multi-platform Local ESXi or VCSA CLI can be access remotely from different clients.

For PowerCLI, finally, the version 10.0.0 provide multi-platform support.

The legacy vSphere Client was only for Windows. But the web clients are multi-platform and multi-browser.
Control CLI provide a better control on what it’s executed (if you know how execute it). GUI can better assist and wizard can drive the user for new tasks.
Completeness Actually you cannot perform every admin task from the CLI, or at least not only with one single CLI. The new HTML5 vSphere Client is still not 100% complete.
Resources Usually the CLI require less system resources on the client than GUI.

But on ESXi or VCSA it’s not clear if there is a real difference between CLI and GUI.

The legacy vSphere Client was a huge client resources consumer.

But also the web clients require more resources compared to the CLI approach.

Requirements In most cases your requirements are satisfied buy your client. For PowerCLI 10.0.0 you need PowerShell Core. The legacy vSphere Client required old version of .NET Framework.

The web clients just a compatible browser, but the vSphere Web Client needs also Flash.

Accuracy CLI is more accurate and precise, just because command behaviour is usually predictable, also across different version of vSphere. GUI may have strange behaviours, for example all the different web clients have different interfaces and not always the same numbers or information.
Scripting and automation Using PowerCLI is really easy build script and automate process. The different vSphere clients are not suitable to build scripting or automation.
Diversity and consistency CLI is usually much “stable” during the years. The big change was with version 5.0 of vSphere were the local ESXi CLI was completely changed. All the different vSphere clients have different aspects and sometimes also different behaviours.

Conclusion

Both CLI and GUI have their advantages and disadvantages, and they are appropriate according to the user requirements, knowledge, skills and use.

The graphic user interface can be more efficiency for new users or users who have to focus on the data visualization; for this reason could be better for operators, although maybe they are accessing other tools, like monitoring tools or cloud management tools.

The command line interface offers more control, precision and repeatability; for this reason could be more powerful for admins, considering also that the vSphere web clients are actually in a “transition” phase with the vSphere Web Client (the only GUI that is actually “complete”) destined to become soon a legacy tool (due to the Flash dependency).

Generically speaking, limiting yourself to graphical user interface maybe be not wise, especially if you have to perform several time the same tasks. The command line interface, can really help you in become more productive but also in building script and make repetitive tasks more controllable and predictable.

But could be is equally unwise to completely ignore the graphical user interfaces because there are situations when using GUI is more productive, for example in data visualization.

Unfortunately, at this time, having a mixed approach with the best of both worlds isn’t easy on VMware vSphere. What will be nice, and increase the adoption of CLI, it’s having the GUI that shows the right commands that can be executed to perform the same task. This will really help to better understand the commands their syntax.

To make an example, use the same approach used by Microsoft System Center or also by the Server Manager, that shows the right PowerShell commands that will be executed.

For the legacy vSphere Client for Windows, there was a nice Flings project (called Onyx), but now for the web clients, there isn’t anything specific.

When there will be only one client (the HTML5 vSphere Client) and also only one type of vCenter Server (the VCSA), maybe will be simpler transform the GUI as a wrapper of the CLI and make this approach more effective. Also with the new version of PowerCLI that it’s finally multi-platform, should be nice if there will be just one main CLI, instead of the plethora of CLI actually available in vSphere (too much languages does not really help in a wide adoption).

Views All Time
6
Views Today
10
Appreciate how useful this article was to you?
1 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 5
5 out of 5, based on 1 review
Loading...
Back to blog
The following two tabs change content below.
Andrea Mauro
Andrea Mauro
Virtualization expert and architect, System Administrator on Linux and Windows OS, network and storage specialist. Holding multiple technical certifications from VMware: (VCDX3, VCDX4, VCDX5-DCV, VCAP4-DCA, VCAP4-DCD, VCAP5-DCA, VCAP5-DCD, VCAP6-DCD, VCAP5-DTD, VCAP5-DTA, VCAP5-CIA, VCAP5-CID, VCIX-NV, VCIX6-DCV,VCP3, VCP4, VCP5-DCV, VCA4-DT, VCP4-DT, VCP5-DT, VCP6-NV, VCP5-Cloud), Microsoft (MCP, MCSA, MCSE, MCTS, MCITP), Citrix (CCA, CCSP). VMware vExpert from 2010 to 2016, Microsoft MVP 2014-16 (on Hyper-V), Veeam Vanguard 2015-2016.