apple

VMware Fusion Powershell community module

10/05/2017 by William Lam 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!

VMware Fusion 2017 Tech Preview adds REST API support

07/18/2017 by William Lam 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

Native OVF support for Fusion/Workstation 2017 Tech Preview

07/18/2017 by William Lam 1 Comment

The VMware Fusion and Workstation team just released their 2017 Tech Preview releases and there is a ton of new and awesome capabilities which you can read more about here and here. One of the exciting new features, which I was very fortunate to have been involved with is finally here, native OVF property support! Although customers have had the ability to import OVF/OVAs for some time now, if they included OVF properties, they would be ignored and often times this would result in a failed deployment as those properties are required for the initial setup.

A great example of this is trying to run the vCenter Server Appliance (VCSA) on either Fusion or Workstation. Today, the only workaround is to manually edit the VMX file and supplying the correct OVF properties which I have blogged about here. With the latest TP release of Fusion/Workstation, when you import an OVF/OVA that contains OVF properties, the UI will automatically render the required information directly into the UI without needing users to manually touch the VMX files.

Here is a screenshot of deploying the latest VCSA 6.5d OVA (jump to bottom for some additional VCSA tidbits when deploying to Fusion/Workstation):

Using vSphere Guest Operations API on macOS Guests?

07/05/2017 by William Lam 2 Comments

I have written a number of articles exploring the usage and some of the cool tricks that the vSphere Guest Operations (GuestOps) feature provides which you can be found here, here, here and here. I have been a huge fan and supporter of GuestOps since the early days where it was formally known as the VIX API. Having used GuestOps across many different GuestOS types including Nested ESXi, I have to admit, I had never tried it against an Apple macOS guests. I recently had a customer reach out who was looking to use the GuestOps API via PowerCLI (Invoke-VMScript) to automate updates against his guestOS templates that span across Windows, Linux and macOS (from 10.7 to latest). The customer was able to get all guestOSes working except for macOS.

Since I had never tried this before, I spun up my Apple Mac Mini which happen to have a macOS 10.11 (El Capitan) guests running. I tried using the vSphere API GuestOps directly to see if this was a PowerCLI and/or API issue. I too ran into issues and after enabling VMware Tools debugging on the guests (which you can find more details below), I found that it hit the following error:

[Jun 28 06:35:42.805] [ debug] [vix] >VixToolsImpersonateUser

[Jun 28 06:35:42.925] [ warning] [vmsvc] Failed to set gid for user root

Reaching out to Engineering regarding the problem, I came to learn that this particular issue was due to a syscall change made by Apple starting with macOS 10.10.3 and newer. Although the change was a positive thing from a security standpoint, it did break the GuestOps functionality. The good news was that this was already resolved with VMware Tools 10.1 or later. When I had initially provisioned the macOS guests, the latest VMware Tools at the time was 9.10.5. After I applied the latest version which is currently 10.1.7, the issue went away and I was able to successfully use the GuestOps API on my macOS guests.

Below are examples of running the system_profiler SPSoftwareDataType command using both the Invoke-VMScript cmdlet as well as the vSphere API and PowerCLI to consume the GuestOps APIs. Both approaches delivers the exact same outcome, the one benefit of using Invoke-VMScript is that if you want to easily return output from a given command, the cmdlet already does the heavy lifting. If you notice in the native vSphere API case, you do not get output but rather just the PID ID. If you want to return the output, you need to first save it into a file and then download the file to your client system, which may not be ideal for interactive usage but it all depends on your use case.

Using vSphere Auto Deploy to Netboot ESXi onto Apple Mac Hardware

01/17/2017 by William Lam 2 Comments

Last week I published an article that demonstrated for the first time on how to netboot an ESXi installation onto Apple Mac Hardware. As you can imagine, this was very exciting news for our VMware/Apple customers, who historically have not had this capability before. Customers can now automate and install ESXi over the network onto their Apple Mac Hardware just like you would for other non-Apple hardware.

With the ability to boot ESXi over the network for Apple Mac Hardware, it is now also possible for customers to take advantage of the vSphere Auto Deploy feature. Auto Deploy allows customers to easily and quickly provision ESXi hosts at scale and integrates directly with vCenter Server to automatically join and apply specific defined host configuration policies. This is a great time to check out Auto Deploy, especially with all the new enhancements that were introduced in vSphere 6.5 like custom script bundles for example.

Below are the instructions on how to setup Auto Deploy to work with Apple Mac Hardware.

How to Netboot install ESXi onto Apple Mac Hardware?

01/13/2017 by William Lam 9 Comments

The ability to perform an ESXi Scripted Installation over the network has been a basic capability for non-Apple hardware customers since the initial release of classic ESX. However, for customers who run ESXi on Apple Mac Hardware (first introduced in vSphere 5.0), being able to remotely boot and install ESXi over the network has not been possible and customers could only dream of this capability which many of us have probably taken for granted.

Unlike traditional scripted network installations which commonly uses Preboot eXecution Environment (PXE), Apple Mac Hardware actually uses its own developed Boot Service Discover Protocol (BSDP) which ESXi and other OSses do not support. In addition, there are very few DHCP servers that even support BSDP (at least this may have been true 4 years ago when I had initially inquired about this topic). It was expected that if you were going to Netboot (equivalent of PXE/Kickstart in the Apple world) a server that you would be running a Mac OS X system. Even if you had set this up, a Netboot installation was wildly different from a traditional PXE installation and it would be pretty difficult to near impossible to get it working with an ESXi image. With no real viable solution over the years, it was believed that a Netboot installation of ESXi onto Mac Hardware just may not be possible.

tl;dr - If you are interested in the background to the eventual solution, continue reading. If not and you just want the goods, jump down a bit further. Though, I do think it is pretty interesting and worth getting the full context 🙂