With the release of vShere 5.0 and the introduction of the new ESXi Image Builder CLI there’s naturally been a good deal of interest in how to create and maintain custom ESXi images. Although I’ve always understood a “VIB” to be the basic building block of an ESXi image, I’ve never really understood what exactly a VIB is. However, the more I work with vSphere 5.0 the more I have come realize that to be successful I need more than a cursory knowledge of VIBs. It’s important to understand the make up of a VIB, how VIBs are created, and how VIBs are packaged and distributed. As such I thought it would be good to write a blog post discussing the elusive ESXi “VIB”.
About VIBs
VIB stands for vSphere Installation Bundle. At a conceptual level a VIB is somewhat similar to a tarball or ZIP archive in that it is a collection of files packaged into a single archive to facilitate distribution. If we look under the covers we will find that a VIB is comprised of three parts:
A file archive
An XML descriptor file
A signature file
The file archive, also referred to as the VIB payload, contains the files that make up the VIB. When a VIB is added to an ESXi image, the files in the VIB payload will be installed on the host. When a VIB is removed from an ESXi image these files are removed.
The XML descriptor file describes the contents of the VIB. Included with the description is important information about the requirements for installing the VIB, to include any dependencies, any compatibility issues, and whether the VIB can be installed without rebooting.
The signature file is an electronic signature used to verify the level of trust associated with the VIB. The acceptance level not only helps protect the integrity of the VIB, but it also identifies who created the VIB and the amount of testing and verification that has been done. There are four acceptance levels:
VMwareCertified: VIBs created and tested by VMware. VMware Certified VIBs undergo thorough testing by VMware.
VMwareAccepted: VIBs created by a VMware partners that are approved by VMware. VMware relies on partners to perform the testing, but VMware verifies the results.
PartnerSupported: VIBs created and tested by a trusted VMware partner. The partner performs all testing. VMware does not verify the results.
CommunitySupported: VIBs created by individuals or partners outside of the VMware partner program. These VIBs do not undergo any VMware or trusted partner testing and are not supported by VMware or its partners.
All VMware and partner supported VIBs must be signed by a VMware trusted authority, this helps ensure the security of the VIB by preventing any unauthorized tampering of its contents. Community supported VIBs do not need to be signed, but they are still required to have an empty signature file. Be careful when using CommunitySupported VIBs as their contents are not tested, monitored or controlled.
Coinciding with the VIB acceptance levels, ESXi Image Profiles also have an acceptance level. When the image is created it is assigned one of the four acceptance levels. Any VIBs added to the image must be at the same acceptance level or higher. This helps ensure that non-supported VIBs don’t get mixed in with supported VIBs when creating and maintaining ESXi images.
How are VIBs created and distributed?
VMware provides its partners with software tools they can use to create VIBs. Once VIBs are created they are packaged into one of two user consumable formats.
Individual VIBs
Vendors can publish individual VIBs. Users can use the ESXCLI command to add and remove individual VIBs to/from their ESXi hosts. However, distributing individual VIBs has a major drawback – the only user-level tool that supports working with individual VIBs is the ESXCLI command. Update Manager and Image Builder cannot work with individual VIBs as they require additional metadata that only comes when VIBs are added to a software bundle.
Software bundle/depot
VIBs are more often distributed as part of a software bundle. Software Bundles include additional metadata that allows the VIBs to be managed not only with the ESXCLI command, but also with Update Manager and the Image Builder CLI. Software bundles can be distributed as a ZIP archive that users download (referred to as an offline bundle or offline depot), or they can be hosted on a web server and accessed remotely using HTTP/FTP (referred to as an online bundle or online depot).
How do I add or remove VIBs from an active ESXi host?
You can use the ESXCLI command to interactively query and manage the VIBs installed on a host. In addition, you can also import a software bundle into Update Manager and use it to manage the VIBs installed on the host.
How do I create a custom ESXi 5.0 image that I can use to install new hosts?
To create a custom ISO image that can be used to install new ESXi hosts you will need to use the ESXi Image Builder CLI. The Image Builder CLI is bundled as part of the vSphere PowerCLI and provides several commands (referred to as cmdlets) that can be used to modify the VIBs that make up an ESXi Image profile, which can then be saved as ISO image.
The typical workflow involves:
Download the default ESXi offline bundle from VMware.
Downloading any additional offline bundle(s) from any partners or 3rd party vendors.
Use the Image Builder CLI to combine the vendor VIBs together with the VIBs provided by VMware.
Save/Export the resultant Image Profile as a custom ISO file.
Use the custom ISO to install new ESXi hosts.
Conclusion
As you can see there is a lot that goes into the making of a VIB, and while most of us will never actually create a VIB it is helpful to understand the underlying components. Of particular importance are the VIB’s XML descriptor file, as this is where we find information about any dependencies or compatibility requirements, and the VIB acceptance level as this is how we now if a VIB is supported. In addition, it’s important to understand the distribution format of the VIB as different tools (i.e. ESXCLI, Update Manager, Image Builder) have different requirements.
