WilliamLam.com

How To Create Offline Update Repository For VMware Virtual Appliances

by // 8 Comments

Virtual appliances built from VMware Studio provides a very easy mechanism of updating or upgrading the software on the appliance by using the VAMI (Virtual Appliance Management Interface) web interface. The VAMI web interface provides three methods of updating or upgrading an appliance: online update repository hosted by the author of the appliance, CD-ROM or alternate update repository can be specified.

UPDATE 02/23/16 - It looks like there were two tiny changes with the latest VAMI Update Repos starting with vCenter Server Appliance (VCSA) 6.0 Update 1. The first being a new signature file called manifest-latest.xml.sign and the .sha256 and .sig files are no longer used or available for download. The second is an additional patch-metadata-scripts.zip file that is under the pool-package directory which maybe required depending on the virtual appliance in question. I have updated my script to take care of these files in case they are needed for newer versions of the VAMI interface.

UPDATE 07/10/15 - VMware has just released a new Fling called VAMI Update Repository Appliance (VURA) which provides an easy way for customers to create offline VAMI repositories for their Virtual Appliances.

For VMware virtual appliances, a VMware hosted update repository is configured by default and internet connectivity to the configured URL will be required (proxy configurations are supported). However, there are environments where network connectivity to VMware's online repository is just not possible or the update repository must be hosted internally due to security requirements and this is where the third option can be used.

The process to setup your own update repository is not really documented and I have been noticing more requests from customers looking for a way to update or upgrade their VMware virtual appliances without requiring access to VMware's online repository. There are also other virtual appliances such as VCSA (vCenter Server Appliance) which ships both the update contents for an ISO and zip file which can then be used with the two other update/upgrade methods.

Though these files can be generated from VMware Studio as part of the appliance build process, the majority of the VMware virtual appliances do not provide these files for download.

I decided to research this topic a bit and look into building my own offline update repository based on the online update repository from VMware. I figured it should be fairly easy to replicate what is being hosted to a local web server that runs within your own datacenter. After some investigation, I found the  process to be pretty straight forward and only requirement is a web server that can be used to host the contents for update repository. In this example, I will show you how to build an update repository to upgrade VIN (vSphere Infrastructure) 1.2 to 2.0.

Step 1 - Login to the VAMI interface of VIN (https://[VIN-IP]:5480) and under the Update tab and make a note of the the default repository URL.

Step 2 - Download buildVARepo.sh shell script and upload that to a Linux based web server which will automatically build out our update repository.

Step 3 - The script accepts two arguments: default repository URL for a particular virtual appliance (from the previous step) and the name of the directory in which the repository will be created. In this example, I will be using the VIN repository URL and I will name the repository vin:

./buildVARepo.sh http://vapp-updates.vmware.com/vai-catalog/valm/vmw/302ce45f-64cc-4b34-b470-e9408dbbc60d/1.2.0.290.latest vin

The system that the script runs will need to have access to the URL above as it needs to download the required manifest files. Using the manifest files, parses out the package name and downloads the RPM packages to the web server using wget.

Step 4 - The result is a directory structure that will look like the following:

vin/manifest = List of XML manifest and signature files that describes the update and the path to the appliance packages
vin/package-pool = The RPM packages for the appliances for a given update

Depending on the location of where the script was executed, you may need to move it to the proper path in which your web server is configured to serve up content. You should be able to open a browser and point that to the /vin directory and view the contents.

Step 5 - We now log back into the VAMI interface and specify our update repository URL which will be http://[IP-OR-HOSTNMAE]/[REPO-NAME] and save the settings.

Step 6 - Now we head over to the Status sub-tab under Update and click on the "Check Updates" and we should see a new update for our virtual appliance. To update the appliance, we then select "Install Updates" and shortly after we should see our VIN appliance upgrade to 2.0

Note: Not all virtual appliances provide upgrades to the latest versions of the appliance, be sure to check the documentation of each individual appliances to see what is supported.

Automating SSL Certificate Regeneration in VCSA 5.1 & 5.5 (vCenter Server Appliance)

by // 4 Comments

The VCSA (vCenter Server Appliance) provides a very simple way of regenerating the self-signed SSL Certificate by using the VAMI web management interface. This is extremely useful if you change the IP Address or hostname of your VCSA and want a proper SSL certificate with the correct common name, especially important if you are plan on using something like vCenter Orchestrator which validates this. To regenerate the SSL Certificate, you just need to login to the VAMI web interface by pointing your browser to the following address: https://[VC-IP]:5480 and under the Admin tab there is a option to "Toggle certificate setting".

After enabling this option, you will need to reboot your VCSA for the new SSL certificate to be generated. Once the VCSA is booted up, you will need to go back into the VAMI interface and disable this setting, else another SSL certificate will be generated upon the next reboot.

I was recently asked if it was possible to automate the SSL regeneration via the command-line without using the GUI which would be very useful for automated VCSA deployments. In looking into this, it turns out the process is quite simple and the present of a file within the VCSA will determine whether a certificate regeneration is required.

To enable certificate regeneration, run the following command which will "touch" (create) allow_regeneration file under /etc/vmware-vpx/ssl directory:

touch /etc/vmware-vpx/ssl/allow_regeneration

To disable certificate regeneration, you just need to remove the file after the VCSA has rebooted. Behind the scenes, this is what is happening when you are toggling the option in the VAMI interface and now you can automate this from the CLI without using the GUI!

UPDATE (09/04/13)

For the new VCSA 5.5, there is a new option that you can specify which will re-generate the SSL certificate and then delete the file without requiring manual intervention after reboot. You would still need to create the /etc/vmware-vpx/ssl/allow_regeneration file but if the contents of the file contains "only-once", it will delete the file automatically which is nice from an Automation perspective.

To re-generate the SSL certificate and automatically have it clean itself up, run the following command:

echo only-once > /etc/vmware-vpx/ssl/allow_regeneration

Automating VCSA Network Configurations For Greenfield Deployments

by // 6 Comments

If you deploy the VCSA (vCenter Server Appliance) or other virtual appliances directly onto an ESXi host,
you will notice the network configuration wizard for the virtual appliance is not available as you would expect when deploying to a vCenter Server.

The reason for this is that ESXi does not support some of the advanced OVF/OVA properties such as the Networking section and you will need to deploy the OVF/OVA to a vCenter Server to be able to configure these advanced options. This poses a problem if you need to deploy the VCSA in a greenfield environment where you will not have an existing vCenter Server running and you will be deploying directly to the ESXi host. Unless you have a DHCP enabled network, you will most likely need to manually go into the vSphere C# Client to change the network configuration as it was unable to obtain an IP Address.

Though this is a one time configuration, it is still not ideal and would require the use of a Windows system to access the vSphere C# Client. You can actually get around this by leveraging the GuestOperations API (previously known as VIX API) which allows you to perform operations within the guestOS that is running VMware Tools. The other nice thing about the GuestOperations API is that it does not require any network connectivity from the virtual machine.

Note: The GuestOperations API can be accessed in variety of ways and in this article I am demonstrating just two methods and does not require a Windows system. You can also access the GuestOperations API using PowerCLI if you are more comfortable with Windows and do not wish to use the vSphere C# Client to manually configure the network settings for the VCSA. I would also like to stress that though this article is about the VCSA, you can easily apply this to any VMware based virtual appliance or virtual appliance running VMware Tools.

The most important thing to identity before using the GuestOperations API is the specific command or program you wish to invoke and the argument it accepts. To configure the network configuration for the VCSA or any other VMware based virtual appliance, you would use /opt/vmware/share/vami/vami_set_network If you just run this command by itself, there are variety of options from IPv4 to IPv6, static or dhcp configuration. In our example, we will be configuring a Static IPv4 address for our VCSA and the command we would run is the following:

/opt/vmware/share/vami/vami_set_network "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1"

Method 1 - Using RVC (Ruby vSphere Console)

 

RVC is a nice open-source tool for interactively managing and configuring your vSphere infrastructure. RVC can be installed on any platform, in this example, I am running RVC on my Apple OS X laptop.

Step 1 - We first need to deploy the VCSA OVA and we can do so by using the ovftool via the command-line which can also be installed on Mac OS X system.

Step 2 - We then login to our ESXi host using RVC.

Step 3 - Next we will need to "change directory" to the location of our VM, in this example my VCSA is called VCSA-5.1. We can then run the "info ." command to view the summary of our VM. We can see that our VM is powered on from our initial deployment and we are ready to apply our network configurations in the next step.

Step 4 - To be able to run the above command, we will need to first authenticate into the guestOS. To do so, we will run the "vm_guest.authenticate ." and we will be prompted for the VCSA password. By default, the command assumes the username is root but that can also be specified on the command-line. If you are successful, you should not see any errors and then we can run the "vm_guest.start_program" command. Run the following to set a IPv4 static IP Address:

vm_guest.start_program . --program-path /opt/vmware/share/vami/vami_set_network --arguments "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1"

Note: All commands in RVC can be tabbed out with auto-completion.

If the command was successful, you can quit RVC and you should be able to ping the IP Address that you have just configured.

Method 2 - Using vSphere SDK for Perl Script

 

Awhile back I wrote a script called guestOperations.pl which is a vSphere SDK for Perl script that implements the new GuestOperations API. This is a generic script which can be used to remotely connect to either a vCenter Server or ESXi host and perform operations within a guestOS as long as VMware Tools is installed and running. In this example, I also have the vSphere SDK for Perl installed on my Mac OS X laptop, but you can also install this SDK on any platform as well.

Step 1 - We will first use the "validate" operation to ensure our credentials to the guestOS is correct, but more importantly ensure that VMware Tools is up and running.

If the operation was successful, we should see our guest credentials validated. If not, you may need to wait a minute or two while VMware Tools is still loading up.

Step 2 - To invoke the command to configure the network configuration, we will use the "startprog" operation and run the following:

./guestOpsManagement.pl --server mini --username root --guestusername root --vm VCSA-5.1 --operation startprog --program_path /opt/vmware/share/vami/vami_set_network --program_args "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1" --working_dir /

If the command was successful, then you should now be able to ping the IP Address that you have just configured.

As you can see, with the use of the GuestOperations API, you can do more than just setup the network configuration for a VM, you can run pretty much any command within the guestOS as you normally would if you were to RDP or SSH in. This is a very powerful interface that you can leverage to help you automate your virtual machine deployment and configurations!