Home > Blogs > VMware vSphere Blog > Tag Archives: VIB

Tag Archives: VIB

Understanding ESXi Patches – Size & Patch Bundles

Posted on by
7

Patch management for ESXi is very different compared to traditional operating system patches, where incremental updates are made to the base operating system and thus increasing the disk footprint for each patch update. For the ESXi hypervisor, when a patch is applied, the entire ESXi image also known as an Image Profile is replaced. This means that each time you patch or upgrade your ESXi host, you are not adding on top of the original installation size.

Continue reading →

Minimum vSphere Privileges To Query VIBs On An ESXi Host

Posted on by
2

This was a recent question that was asked internally about the minimum privileges required to query VIBs on an ESXi host. The request was for a custom script that was developed for compliance check and the customer was looking to create a custom vSphere role to minimize the privileges needed to perform the task. Since I did not know the answer, it was off to the lab for some testing. Through the process of elimination, it turns out the only privilege that is required for querying VIBs on an ESXi host is Global.Settings.

In the example above, I created a custom vCenter Server Role called VIBQuery and enabled the Global.Settings privilege and assigned the role to a user. The custom role can be created on both a vCenter Server as well as directly on an ESXi host. By using vCenter Server, one can benefit from centralize management of user access to all ESXi hosts in the environment.

To confirm that our user assigned to the new role can query VIBs on an ESXi host, we will  run the following ESXCLI command:

esxcli --server [VC-SERVER] --vihost [ESXi-SERVER] --username [USER] software vib list

We can also confirm that we can do the same directly on the ESXi host by running the following ESXCLI command:

esxcli --server [ESXi-SERVER] --username [USER] software vib list

When granting access to your vSphere infrastructure, you should always use good security practices by leveraging RBAC model (Role-Base Access Control) and restrict the amount permission a user has access to.

UPDATE: In addition to using ESXCLI, there are two additional options to query installed VIBs on an ESXi host as noted by the comment below by Mike.

Get notification of new blog postings and more by following lamw on Twitter:  @lamw

Introducing the VIB Author Fling

Posted on by
1

I’m very excited to announce the new vibauthor fling.  This fling is hot off the press and provides the capability to create custom vSphere Installation Bundles (VIBs).  Prior to this fling the VIB authoring tools were only available to VMware partners, this fling now extends this capability to everyone.

There are a couple of use cases for creating custom VIBs.  For example, if you are using Auto Deploy and you need to add a custom firewall rule to your host, or you need to make a configuration change that can’t be made using Host Profiles.

One word of caution however, the ability to create custom VIBs does come with some responsibility.  If you plan to create your own VIBs here are a few things to keep in mind:

  1. VIBs provided by VMware and trusted partners are digitally signed, these digital signatures ensure the integrity of the VIB.  Custom VIBs are not digitally signed.  Be careful when adding unsigned VIBs to you ESXi hosts as you have no way of vouching for the integrity of the software being installed.
  2. Before adding a custom VIB you will need to set your host’s acceptance level to “Community Supported”.   When running at the community supported acceptance level it’s important to understand that VMware support may ask you to remove any custom VIBs.   Here’s the formal disclaimer:

“IMPORTANT If you add a Community Supported VIB to an ESXi host, you must first change the host’s acceptance level to Community Supported. If you encounter problems with an ESXi host that is at the CommunitySupported acceptance level, VMware Support might ask you to remove the custom VIB, as outlined in the support policies:”

 

If you are not familiar with VIBs I recommend you start with a quick review of this blog: http://blogs.vmware.com/esxi/2011/09/whats-in-a-vib.html

With that, I know several folks have been chomping at the bit to create their own custom VIBs so I’ve attached a short tutorial that shows how to use the vibauthor tool to create a  VIB to add a custom firewall rule.

Enjoy!

vibauthor-how-to-v0.1

Using the vSphere ESXi Image Builder CLI

Posted on by
5

Kyle Gleed, Sr. Technical Marketing Architect, VMware

I’ve had several requests for a brief tutorial on using the vSphere ESXi Image Builder CLI. I hope this post will help people better understand the power of the Image Builder CLI and how easy it is create and maintain custom ESXi installation images.

Before I get into using the Image Builder CLI lets review some basic terminology:

  • vSphere Installation Bundle (VIB): VIBs are the building blocks of the ESXi image. A VIB is akin to a tarball or ZIP archive in that it is a collection of files packaged into a single archive. A detailed description of a VIB can be found here.
  • Software Depot: Software depots are used to package and distribute VIBs. A Software Depot (sometimes referred to as a Software Bundle) is a collection VIBs specially packaged for distribution. There are two types of depots – online and offline. An online software depot is accessed remotely using HTTP. An offline software depot is downloaded and accessed locally.
  • Image Profile: An Image Profile is the logical collection of VMware and third-party VIBs needed to install an ESXi host. Image profiles created with the Image Builder CLI can be saved as ZIP archives or ISO files.

Continue reading →

Quickest Way to Patch an ESX/ESXi Using the Command-line

Posted on by
33

By William Lam, Sr. Technical Marketing Engineer

As you know, when it comes to automating patch management for your vSphere infrastructure, we highly recommend leveraging our vSphere Update Manager (VUM) which is part of the vSphere vCenter Suite to help simplify the update process. Though not all environments have the luxury of running vCenter Server to manage their ESX(i) hosts. An example of this could be 1-2 hosts running at a ROBO (remote office/branch office) site or single test/dev host in a home or office lab where VUM is not available.

However, it is still possible to patch/upgrade your ESX(i) host using the command-line without the need of VUM, but you will have to manually identify the patch dependencies and ensure host compliance.

Depending on the version of ESX or ESXi you are running, you may have several options that could include local and/or remote command-line utilities that are available in following four forms:

  • ESX Service Console
    • esxupdate – Local utility found on classic ESX hosts to manage/install patches
  • ESXi Shell
    • ESXCLI – Local utility found on ESXi 5.0 hosts that can be used manage/install patches
  • vCLI (Windows/Linux or use vMA)
    • vihostupdate35 – Remote utility to manage/install patches for ESXi 3.5
    • vihostupdate – Remote utility to manage/install patches for ESX(i) 4.0 & 4.1
    • ESXCLI – Remote utility to manage/install patches for ESXi 5.0 (patch capability introduced in vSphere 5 for ESXi 5.0 hosts only)
  • PowerCLI(Windows)
    • InstallVMHostPatch – Remote utility using PowerCLI to manage/install patches for ESX(i) 4.0 and 4.1

Note: If you are using vSphere Hypervisor (Free ESXi), you will not be able to leverage any of the the remote CLI’s but you can still use the local CLI.

Here is a table summarizing all available command-line options based on the version of ESX(i) you are running:

Hypervisor Version Local Command vCLI Remote Command PowerCLI Remote Command
ESX 3.5 esxupdate −−bundle=<zip> update N/A N/A
ESXi 3.5 N/A vihostupdate35
−−bundle=<zip> −−install		 N/A
ESX 4.0 esxupdate −−bundle=<zip> update vihostupdate <<bundle=<zip> −−install Install-VMHostPatch
ESXi 4.0 N/A vihostupdate −−bundle=<zip> −−install Install-VMHostPatch
ESX 4.1 esxupdate −−bundle=<zip> update vihostupdate −−bundle=<zip> −−install Install-VMHostPatch
ESXi 4.1 N/A vihostupdate −−bundle=<zip> −−install Install-VMHostPatch
ESXi 5.0 esxcli software vib update −−depot=/vmfs/volumes/[datastore]/<zip> esxcli software vib update −−depot=/vmfs/volumes/[datastore]/<zip> Install-VMHostPatch
Or Get-ESXCLI with the local command referenced in this table.

Note: When you download patches from VMware, there is an associated VMware KB article and it provides a link to the patch management documentation. You should always refer to that for more details and information for different methods of applying a patch.

Here is an example of using esxupdate on a classic ESX host. The patch bundle needs to be uploaded to ESX host using scp or winSCP and then specifying the full path on the command-line:

$ esxupdate −−bundle=ESX400-200907001.zip update

Here is an example of using the remote vihostupdate utility for an ESXi host, you will need to specify the ESXi host using the −−server parameter and −−username/−−password for remote authenication. You may choose to leave off −−password and you will be prompted to enter your credentials. The patch bundle does not need to be uploaded to ESXi host, it can reside on the system that is running the vihostupdate command. During the execution, the patch bundle will automatically be transfered to the host:

$ vihostupdate −−server [ESXI-FQDN] −−username [USERNAME] −−bundle=ESXi410-201011001.zip −−install

Here is an example of using the local esxcli utility for an ESXi 5.0 host. The patch bundle needs to be uploaded to ESXi host using scp or winSCP and then specifying the full path on the command-line:

$ esxcli software vib update −−depot=/vmfs/volumes/datastore1/ESXi500-201112001.zip

Here is an example of using the remote esxcli utility for an ESXi 5 host, you will need to specify the ESXi host using the −−server parameter and −−username/−−password for remote authenication. You may choose to leave off −−password and you will be prompted to enter your credentials. The patch bundle needs to be uploaded to ESXi host using scp/winSCP or vCLI’s vifs utility and then specifying the full path on the command-line:

$ vifs −−server [ESXI-FQDN] −−username [USERNAME] -p ESXi500-201112001.zip “[datastore1] ESXi500-201112001.zip”
$ esxcli −−server [ESXI-FQDN] −−username [USERNAME] software vib update −−depot=/vmfs/volumes/datastore1/ESXi500-201112001.zip

Note: In ESXi 5, −−depot only supports local server path or remote URL. The latter is to help centralize the location of your patches and help reduce manual transfer. This is why you need to transfer the patch to host if you do not have a patch depot.

Here is an example of using Install-VMHostPatch utility for an ESXi host:

Get-VMHost ESXI-FQDN | Set-VMHost -State Maintenance
$DS = Get-VMHost ESXI-FQDN | Get-Datastore datastore1
Copy-DatastoreItem C:\tmp\ESXi500-201112001\ $DS.DatastoreBrowserPath -Recurse
Get-VMHost ESX-FQDN | Install-VMHostPatch -Hostpath “/vmfs/volumes/datastore1/ESXi500-201112001/metadata.zip”

Note: The Install-VMHostPatch cmdlet does have a -LocalPath parameter for you to specify a local path to the patch. For larger files it is recommended you use the Copy-Datastore cmdlet to upload the file to a datastore on the host and then the -HostPath parameter as can be seen in the example above.

As you can see over the releases, we have had several methods of patching a host using the command-line both locally/remotely and it may not always be intuitive. When we converged to only ESXi with the release of vSphere 5.0, you will see that patching from the command-line has also converged to a single command-line utility using ESXCLI and a common patch format called a VIB. ESXCLI was first introduced in vSphere 4.0 and it had some limited capabilities. With vSphere 5.0, it has been significantly enhanced and now supports patching as one of it’s many capabilities. The syntax and expected output is exactly the same if you execute ESXCLI locally or remotely on an ESXi host with the exception of the remote authentication that is required for a remote execution. This should provide for a better user experience and consistency going forward.

An alternative method to patching from the command-line if you do not have VUM is using VMware Go, which is an online service (SaaS) provided by VMware. VMware Go can help manage your ESXi host but it also provides a patching capability similar to that of VUM.

Get notification of new blog postings and more by following lamw on Twitter:  @lamw