Workstation – Page 4

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):

[Read more...]

How to deploy the vCenter Server Appliance (VCSA) 6.5 running on VMware Fusion & Workstation?

10.27.2016 by William Lam // 31 Comments

As with any new release of vSphere, it is quite common for customers to deploy the new software in either a vSphere home or test lab to get more familiar with it. Although not everyone has access to a vSphere lab environment, the next best thing is to leverage either VMware Fusion or Workstation. With the upcoming release of vSphere 6.5, this is no different. In fact, during the vSphere Beta program, this was something that was asked about by several customers and something I had helped document as the process has changed from previous releases of the VCSA.

In vSphere 6.5, the VCSA deployment has changed from a "Single" monolithic stage where a user enters all of their information up front and the installer goes and deploys the VCSA OVA and then applies the configurations. If you had fat finger say a DNS entry or wanted to change the IP Address before applying the actual application configurations, it would not be possible and you would have to re-deploy which was not an ideal user experience.

In vSphere 6.5, the new UI installer will still allow you to perform a "Single" monolithic stage but it is now broken down into two distinct stages as shown below with their respective screenshots:

Stage 1 - Initial OVA deployment which includes basic networking

Stage 2 - Applying VCSA specific personality configuration

Just like in prior releases of the VCSA, the UI translates the user input into specific OVF properties which are then passed into the VCSA guest for configuration. This means that if you wish to deploy VCSA 6.5 running Fusion or Workstation, you will have two options to select from. You either deploy VCSA and complete both Stage 1 and 2 or just Stage 1 only. If you select the latter option, to complete the actual deployment, you will need to open a web browser to the VAMI UI (https://[VCSA-IP]:5480) and finish configuring the VCSA using the "Setup vCenter Server Appliance" option as shown in the screenshot below.

If your goal is to quickly get the VCSA 6.5 up and running, then going with Option 1 (Stage 1 & 2 Config) is the way to go. If your goal is to learn about the new VCSA UI Installer, then you can at least get a taste of that by going with Option 2 (Stage 1 Config) and this way you can step through Stage 2 using the native UI installer.

One last thing I would like to mention is that there have been a number of new services added to the VCSA 6.5. One example is that vSphere Update Manager (VUM) is now embedded in the VCSA and it is also enabled by default. With these new services, the tiniest deployment size is going to require 10GB of memory where as before it was 8GB. This is something to be aware of and ensure that you have adequate resources before attempting to deploy the VCSA or else you may see some unexpected failures while the system is being configured.

Note: If you have access to fast SSDs and would like to overcommit memory in Fusion or Workstation, you might be able to get this to work leveraging some tricks mentioned here. This is not something I have personally tested, so YMMV.

Here are the steps to deploy VCSA 6.5 using either VMware Fusion or Workstation:

Step 0 (Optional) - Familiarize yourself with setting up VCSA 6.0 was on Fusion/Workstation with this blog post which will be helpful for additional context.

Step 1 - Download & extract the VCSA 6.5 ISO

Step 2 - Import the VCSA OVA which will be located in vcsa/VMware-vCenter-Server-Appliance-6.5.0.5100-XXXXXX_OVF10.ova using either VMware Fusion or Workstation (you can either double click or just go to File->Open) but make sure you do NOT power it on after deployment. (this is very important)

Step 4 - Locate the directory in which the VCSA was deployed to and open up the VMX file and append one of the following options (make sure to change the IP information and passwords based on your environment):

Option 1 (Stage 1 & 2 Configuration):

guestinfo.cis.deployment.node.type = "embedded"
guestinfo.cis.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.mode = "static"
guestinfo.cis.appliance.net.pnid = "192.168.1.190"
guestinfo.cis.appliance.net.addr = "192.168.1.190"
guestinfo.cis.appliance.net.prefix = "24"
guestinfo.cis.appliance.net.gateway = "192.168.1.1"
guestinfo.cis.appliance.net.dns.servers = "192.168.1.1"
guestinfo.cis.appliance.root.passwd = "VMware1!"
guestinfo.cis.appliance.ssh.enabled = "True"
guestinfo.cis.deployment.autoconfig = "True"
guestinfo.cis.appliance.ntp.servers = "pool.ntp.org"
guestinfo.cis.vmdir.password = "VMware1!"
guestinfo.cis.vmdir.site-name = "virtuallyGhetto"
guestinfo.cis.vmdir.domain-name = "vsphere.local"
guestinfo.cis.ceip_enabled = "False"

Option 2 (Stage 1 Only Configuration):

Step 5 - Once you have saved your changes, go ahead and power on the VCSA. At this point, the guestinfo properties that you just added will be read in by VMware Tools as the VCSA is booting up and the configuration will begin. Depending on the speed of your hardware, this can potentially take up to 15min+ as I have seen it. Please be patient with the process. If you wish to check the progress of the deployment, you can open a browser to https://[VC-IP]:5480 and you should see some progress or you can periodically connect to the Hostname/IP Address and once it is done, you should be taken to the vCenter Server's main landing page.

VM serial logging to the rescue for capturing Nested ESXi PSOD

03.21.2016 by William Lam // Leave a Comment

I frequently deploy pre-releases of our software to help test and provide early feedback to our Engineering teams. One piece of software that I deploy some what frequently is our ESXi Hypervisor and the best way to deploy it, is of course inside of a Virtual Machine or commonly referred to as Nested ESXi.

Most recently while testing a new ESXi build in my lab (screenshot below is for demo purposes, not the actual PSOD image), I encountered an ESXi purple screen of death (PSOD) during the bootup of the ESXi Installer itself. Since ESXi had not been installed, there was no place for ESXi to actually store the core dumps which made it challenging when filing a bug with Engineering as screenshots may not always contain all the necessary details.

Luckily, because we are running in a VM, a really neat feature that VMware has supported for quite some time now is configuring a virtual serial port for logging purposes. In fact, one of the neatest feature from a troubleshooting standpoint was the introduction of the Virtual Serial Port Concentrator (vSPC) feature in vSphere 5.0 which allowed a VM to log directly to a serial console server just like you would for physical servers. You of course had few other options of either logging directly to the serial port of the physical ESXi, named pipe or simply to a file that lived on a vSphere Datastore.

Given this was a home lab setup, the easiest method was to simply output to a file. To add a virtual serial port, you can either use the vSphere Web/C# Client or the vSphere APIs. Since this is not something I need to do often, I just used the UI. Below is a screenshot using the vSphere Web Client and once you have added the virtual serial port, you need to specify the filename and where to the store the output file by clicking on the "Browse" button.

If the GuestOS which includes ESXi has been configured to output to a serial port, the next time there is an issue and you can easily captured the output to a file instead of just relying on a screenshot. One additional tip which might be useful is by default, vSphere will prompt whether you want to replace or append to the configured output file. If you wish to always replace, you can add the following VM Advanced Setting and you will not get prompted in the UI.

answer.msg.serial.file.open = "Replace"

Virtual serial ports are supported on both vSphere (vCenter Server + ESXi) as well as our hosted products VMware Fusion and Workstation.