WilliamLam.com

ESXi host with network redundancy using NSX-T and only 2 pNICs?

by // 8 Comments

In todays data centers, it is not uncommon to find servers with only 2 x 10GbE network interfaces, this is especially true with the rise of Hyper-Converged Infrastructure over the last several years. For customers looking to deploy NSX-T with ESXi, there is an important physical network constraint to be aware of which is quickly mentioned in the NSX-T documentation here.

For example, your hypervisor host has two physical links that are up: vmnic0 and vmnic1. Suppose vmnic0 is used for management and storage networks, while vmnic1 is unused. This would mean that vmnic1 can be used as an NSX-T uplink, but vmnic0 cannot. To do link teaming, you must have two unused physical links available, such as vmnic1 and vmnic2.

As shown in the diagram below, an ESXi host with only two physical NICs can not provide complete network redundancy as each pNIC can only be associated with a single switch (VSS/VDS or the new N-VDS) as pNICs can not be shared across switches.


For customers, this means that you need to allocate a minimum of 4 pNICs to provide redundancy for both overlay traffic and non-overlay VMkernel traffic such as Management, vMotion, VSAN, etc. This is much easier said than done as not all hardware platforms can easily be expanded and even if they can, there still is a huge cost in expanding the physical network footprint (switch port, cabling, etc).

UPDATE (06/12/18) - As of NSX-T 2.2, which was recently released, there is now a UI in NSX-T Manager for managing the migration of VMkernel interfaces to the N-VDS. For automation purposes, you may still find this article useful but now you have option of using the UI.

[Read more...]

VMware Fusion Powershell community module

by // 1 Comment

During the VMware Fusion 2017 Tech Preview, I was experimenting around with the new Fusion REST API and I had built a small prototype PowerShell Module as a way for me to learn how the API works. This allowed me to provide valuable feedback back to the Fusion Engineering team on improving the REST API UX. I was pleasantly happy to see that the majority of the feedback was indeed implemented for Fusion 10 which GA'ed a few weeks back.

Given the PowerShell module was pretty useful for my own use, I figure I would also publish it for others who might also be interested in Automating VM management using the new Fusion REST API, especially those with a PowerShell/PowerCLI background. Another nice thing about the module is that it can run across macOS/Linux via PowerShell Core or Windows using full blown PowerShell. I have been slowly tweaking the module to include the updated REST API changes and I am please to announce that the VMware.Hosted PowerShell Module which supports the new Fusion 10 REST API is now available!

The module includes the following 14 functions:

  • Connect-HostedServer
  • Disconnect-HostedServer
  • Get-HostedNetworks
  • Get-HostedVM
  • Get-HostedVMNic
  • Get-HostedVMSharedFolder
  • New-HostedVM
  • New-HostedVMSharedFolder
  • Remove-HostedVM
  • Remove-HostedVMSharedFolder
  • Resume-HostedVM
  • Start-HostedVM
  • Stop-HostedVM
  • Suspend-HostedVM


If you have ever used PowerCLI before, these functions should feel very familiar. We have basic Connect/Disconnect-HostedServer which will set an environmental variable called $DefaultHostedServer. This variable contains some basic information about the Fusion API endpoint as well as the base64 encoded credentials which are required when connecting to the new Fusion API. Below are a few examples using the new Fusion module, they are pretty basic and I have only implemented a sub-set of the Fusion REST API, so any community contributions are most welcome!

[Read more...]

VMware Fusion 2017 Tech Preview adds REST API support

by // 2 Comments

In case you have not heard the news, the VMware Fusion and Workstation team just released their 2017 Tech Preview releases which you can read more about it here and here. A couple of years back, VMware had released a slimmed down desktop Hypervisor based on VMware Fusion called AppCatalyst which was optimized for developers wanting to run Docker Containers. Although the feedback for AppCatalyst was positive, the large majority of customers preferred to see the AppCatalyst specific features such as the RESTful API to just be included natively within Fusion rather than having a separate product.

Although it could not be said at the time, the feedback was heard loud and clear and the plan was to pull in the AppCatalyst REST API directly into Fusion. With the Fusion 2017 Tech Preview, you will now be able to interact with your Virtual Machines running on Fusion using the new Fusion REST API which also includes some additional new capabilities that was not there with the AppCatalyst REST APIs such as network and port forwarding management.

UPDATE (09/27/17) - VMware Fusion 10 has just officially GA'ed and there have been number of updates and enhancements since the Tech Preview. From an Automation/API standpoint, there have been several major updates that I would like to call out.

First, there are several new command-linen options to the vmrest utility including support for both HTTP and HTTPS API endpoints, credentials are also now supported so you can setup a shared username/password and ensure that only authorized folks can login to the API and lastly, the default port is now also configurable. Along with these widely requested features during the Tech Preview, there is also a nice debugging option while using the Fusion UI for troubleshooting purposes.

Secondly, the Fusion Swagger REST API docs has received a total re-vamp in terms of organization and cleaned up documentation. Below is a screenshot of the Swagger interface for the GA version of Fusion 10 which should make it even easier to consume the REST API.

Getting Started

Step 1 - Once you have installed the Fusion 2017 TP release, you will need to start the REST API endpoint which is provided by /Applications/VMware Fusion Tech Preview.app/Contents/Public/vmrest You can just type vmrest and it should automatically start or if you prefer to run it in the background, just type the following:

vmrest &

Here is screenshot of starting the Fusion REST API endpoint:


Note: The default port for the REST API is 8697

[Read more...]