WilliamLam.com

Search Results for: ovftool

Packer reference for PhotonOS Arm NFS Virtual Appliance using OVF properties for ESXi-Arm

by // 5 Comments

In case the title was not descriptive enough, I was curious if I could build an Arm Virtual Appliance (OVA) using OVF properties that would allow for all sorts of interesting guest customizations which I have blogged about before here, here, here and here using x86 PhotonOS as a reference implementation. My idea for this actually pre-dated the release of the ESXi on Arm Fling, but it was only until recently with support for VMware Tools for Photon OS Arm, was I able to finally piece together this solution.

It was also neat to see that I could build an Arm OVA using x86 tooling (Packer and OVFTool) which ran on my desktop and you simply needed an ESXi-Arm host. This really goes to show the level of compatibility from a management and vSphere API point of view that an ESXi-Arm host behaves just like a standard x86 ESXi host!

To demonstrate a more interesting use case than just basic network customization for the ?first? Arm OVA, I thought it would be useful to setup a simple NFS appliance that would take input from the user such the size of the exported volume (default 60GB) and then the name of the mount point. Upon first boot up, there is a guest customization script that would read in the OVF properties and configure the networking, OS password and NFS server configuration which you can certainly use to host your Arm VMs.

[Read more...]

Big updates to the vCenter Event Broker Appliance (VEBA) Fling

by // 1 Comment

The vCenter Event Broker Appliance (VEBA) team has been working hard over the last couple of months on some pretty exciting enhancements and today we are pleased to announce the release of VEBA v0.3 which can be download from the VMware Fling site. Although this is a "dot" release, do not let that fool you as this release contains a large number updates including a major re-architecture in how events are consumed and processed at the core of VEBA.

While this re-architecture does introduce some breaking changes, it does unlock a number of new capabilities that our current users have been asking for. It also provides us with a solid foundation for delivering on future enhancements such as multi-vCenter Server support and additional event sources from NSX-T, vSAN and other VMware Cloud Services to just name a few. Today, the "V" in VEBA stands for vCenter, but in the future, I do see it changing to just "VMware" as it can support so many other solutions.

Having said that, some of the breaking changes also improves the overall user experience, especially as it relates to defining and consuming vCenter Server events as well as troubleshooting and debugging. The team is super excited to get this release in the hands of our community and we look forward to hearing your feedback!

What's New:

  • Introduction of the VMware Event Router which provides a modular and flexible architecture for decoupling the stream "Providers" such as vCenter Server from the actual stream "Processors" like OpenFaaS. More details including its architecture and design can be found here

[Read more...]

How to deploy the vCenter Server Appliance (VCSA) with a custom MAC Address?

by // 8 Comments

I recently had a question that came in from our field where a customer needed to deploy the vCenter Server Appliance (VCSA) with a specific MAC Address which was a requirement to ensure property connectivity within their network. This type of network requirement is not really new or unique, it is a common practice used to ensure only valid VMs with a static DHCP reservation can actually connect to a specific network but it certainly was the first time I had heard of this request for the VCSA.

With the default VCSA installer workflow, there is currently not a way to modify the network MAC Address which is automatically generated after the deployment of the OVA. Having said that, I have spent quite a bit of time exploring the various non-standard methods of deploying the VCSA in the past (see here, here and here) and with that information, you definitely can affect the MAC Address while still maintaining a valid VCSA deployment. With a bit of trial/error, there are two options depending if you are deploying the VCSA directly to an ESXi host (for initial setup) or to an existing vCenter Server. To demonstrate how this works, I have created a basic shell script called VCSAStaticMACAddress.sh which you can easily adapt to for a Windows-based environment.

The trick is that when you deploy to a vCenter Server endpoint, the required OVF properties are persisted which would allow you to only deploy the VCSA but not actually power it on and there you can easily augment a number of settings including the MAC Address. In the case of deploying directly to an ESXi host, OVF properties are not persisted and hence a challenge if you wish to make changes prior to powering on the VM. In earlier versions, it was possible to set these OVF properties by way of using the extraConfig property of the VM but it looks like this trick no longer works and requires a slight variation of the workflow which is described in the instructions below.

[Read more...]