WilliamLam.com

How to Deploy ESXi 5 Using Razor & Puppet

by // 17 Comments

Earlier this week the extraordinary uber super star Nicholas Weaver released a new open source project that he's been working on called Razor (not related to vShaving). I would highly recommend you check out his blog post here for more details about the project. Since Razor deals with Automation which I am always interested, I decided to give Razor a try and see how easy it is to install, configure and deploy.

I also want to mention that this was my first time using Puppet and though there are some videos and guides, it still may not be trivial for new users on what is needed. I thought I walk you through the steps I took to quickly stand up several ESXi 5 hosts in minutes using Razor.

Step 1 - Install Ubuntu Precise (Ubuntu Server 12.04 LTS) which will be your Razor server

Step 2 - For a clean installation of Precise, you will need two additional packages: git and make as well as Puppet. Using the following command, it will pull down the latest updates as well as adding the apt.puppetlabs.com repot to install Puppet:
Note: Thanks to Nan Liu for this quick snippet!

Step 3 - You will need to change the ownership of puppet module directory by running the following command:

chown -R puppet:puppet /etc/puppet/modules

Step 4 -  To verify that you have successfully installed Puppet 2.7.14, you can run the following command which should return you the version:

puppet --version

Step 5 -  Now you will install the Razor module using puppet by running the following command:

puppet module install puppetlabs/razor

Step 6 - Next you will initialize and setup Razor by running the following command (this will take a few minutes to complete):

puppet apply /etc/puppet/modules/razor/tests/init.pp --verbose

Step 7 -  Now to verify that Razor has been properly installed, we will go ahead and run it and it should return you the usage options. The path to the razor command is under /opt/razor/bin/razor and we will go ahead and add it to our system path so we can just run "razor". Run the following commands:

export PATH=$PATH:/opt/razor/bin
razor

Step 8 -  Finally we also need to ensure that the Razor web services is running, this is currently a known issue which hopefully will be fixed very soon. By default, the web service should automatically start by itself, but currently you need to manually start it. You can run the following commands to verify the status and then start it:

/opt/razor/bin/razor_daemon.rb status
/opt/razor/bin/razor_daemon.rb start

Step 9 - When you power on your host, Razor will need to load a micro-kernel (MK) image for it to register with the Razor server and provide information about your bare metal host or VM. The following command will download and import the MK ISO image into Razor:

wget https://github.com/downloads/puppetlabs/Razor/rz_mk_dev-image.0.8.8.0.iso
razor image add mk ./rz_mk_dev-image.0.8.8.0.iso

Step 10 - Razor automatically comes with a TFTP server, you just need to have a DHCP server which will forward the request to the Razor server. I will assume you have or know how to setup a DHCP server and here is an example of what my DHCP configuration  looks like for several "virtual" ESXi Shells which I plan on provisioning with ESXi 5:

Note: You just need to set the next-server stanza to your Razor server and the filename to "pxelinux.0" which exists on Razor server

Step 11 - To verify we have no nodes that have registered with Razor, we can run the following command:

razor node

Step 12 - To deploy ESXi 5 on our hosts, we will need a copy of the ESXi 5.0 ISO. In this example I am importing the latest ESXi 5.0 Update 1 image using the following command (you will need to download and upload the ISO to your Razor server via SCP/WinSCP):

razor image add esxi VMware-VMvisor-Installer-5.0.0.update01-623860.x86_64.iso

Note: You will notice the type for the image is "esxi" versus "os" if you are planning on installing regular guestOSes.

Step 13 - Next we will create a Model which describes an ESXi 5 install and it's configurations. You will need to make a note of the UUID of the ISO we just uploaded from the previous step. Run the following command to create the model:

razor model add template=vmware_esxi_5 label=install_esxi5 image_uuid=5JC9GT8GToMak0DD3Uivke

Note: You will also be asked to fill out a few properties such as the license and password for your ESXi host as well as the network information. If you are interested in the kickstart that is being used for the ESXi deployments, you can take a look at /opt/razor/lib/project_razor/model/esxi/5/kickstart.erb. If you would like to adjust the kickstart file, be sure to take a look here.

Step 14 - Okay, we are almost done! Now we just need to create a policy which binds the model to some set of attributes, such as the tags on our ESXi hosts that we wish to build. In my lab, I created a few vESXi hosts using steps found here and then creating a few Linked Clones so I did not have to waste any storage space using this script here. If you are using a vESXi host, by default you will get the vmware_vm tag which is what our base our policy on. Run the following command to create the policy:

razor policy add template=vmware_hypervisor label=install_esxi5 model_uuid=2w1QEGbkoXDELc6ndXb13A broker_uuid=none tags=vmware_vm enabled=true

Note: You will need the UUID of the model you just created which is highlighted in blue in the previous screenshot when creating the policy.

Step 15 - We can check our policy and confirm there are no nodes registered to Razor again, by running the following commands:

razor policy
razor node

Step 16 - Now you are ready to power on your hosts and they should automatically get an IP Address from your DHCP server and forward your request to Razor and perform an iPXE boot.

Step 17 - Once the hosts have booted up the MK image and register with Razor, you should be able to run the following commands to see the nodes and their states:

razor policy
razor policy active

As you can see from the screenshots, I have 5 nodes that have registered and 4 of them are already in the postinstall process and the ESXi installation should be completely very shortly. If you head over to your hosts, you see that ESXi is completely installed and ready for use:

So there you have it, you can quickly provision from bare metal to a fully functional working ESXi 5 hosts literally within minutes (after the config setup of course). I still think there could be some improvements on the CLI help options (though Razor is still in beta), it was not always intuitive on the options for the commands and luckily I had Nick's video and the Wiki to help out with the options. All in all, Razor was very easy to use (especially for a first timer like myself) and though I was not able to get the vCenter Server modules to work ... since they haven not been released yet ;). I am really looking forward to seeing those modules get released soon by Puppetlabs.

If you are interested in learning more about Razor, I highly recommend you check out Nick's blog here as well as the Razor project's Wiki on Github here and help provide feedback or even contribute code back to the project. Great job again Nick and team!

How to Deploy an OVF/OVA in the ESXi Shell

by // 54 Comments

I recently answered, what I thought was pretty straight forward question on the VMTN forums about whether it was possible to to deploy an OVA directly onto an ESXi host without leveraging remote tools such as the vSphere Client or the ovftool. The response that I provided was, no it was not possible to deploy an OVF/OVA within the ESXi Shell and recommended the user to take a look at the vSphere Client or the ovftool.

For whatever reason, my brain decided to ponder about this specific question over the weekend (even though I had answered dozen or so questions earlier in the week) and came up an idea that could make this work. As many of you know, I am a big fan of the ovftool and I have written several articles about the tool such as here and here. I wanted to see if I could get the ovftool to run in the ESXi Shell as all the necessary libraries and required packages are all self contained within /usr/lib/vmware-ovftool directory. If this works, it would allow a user to deploy a VM from an OVF or OVA format within the ESXi Shell and would not require a remote system which is great for kickstart deployments or ISO installations. As you probably have guessed, I was able to get this to work 🙂

Disclaimer: This is not officially supported by VMware, please test this in a lab before deploying on production systems.

Before you begin, you will need to get the ovftool installed on an existing Linux system, you can use vMA for your convenience. Next, you will need to use the scp command to copy the entire /usr/lib/vmware-ovftool directory onto an ESXi host. Ensure you place the contents on either a shared or local datastore as the size of the ovftool content is quite large (~119 MB).

In this example, I am scp'ing the ovftool directory to a local VMFS datastore (/vmfs/volumes/datastore1)

scp -r /usr/lib/vmware-ovftool/ root@vesxi50-7:/vmfs/volumes/datastore1

Once you have successfully copied the ovftool directory over to your ESXi host, you will need to make a small tweak to the file located in /vmfs/volumes/datastore1/vmware-ovftool/ovftool (shell script that calls the ovftool binary). You will need to modify the the first line using the vi editor from #!/bin/bash to #!/bin/sh as ESXi does not recognize the bash shell. You are now ready to copy an OVF or OVA to your ESXi host which should also reside within a shared or local datastore.

In this example, I uploaded a SLES OVF to the same datastore which contains the ovftool as seen below from the datastore browser:

Let's go ahead and perform a simple probe operation on the OVF we just uploaded to ensure that ovftool is working as expected. To do so, you just need to specify the full path to the ovftool as well as the full path to either your OVF or OVA file.

Note: The ovftool does take slightly longer to run in the ESXi Shell compared to a regular system with the ovftool installed.

Now that we have confirmed the ovftool is working, let's go ahead and deploy from the OVF image. Even though we are running the ovftool locally in the ESXi Shell, you will still need to specify the credentials to your ESXi host during deployment as ovftool was not designed for this use case.

Note: You must specify both the username and password in the ovftool command line, as the password prompt does not function properly in the ESXi Shell and you will see a looping of  "*" characters on the screen.

If you are familiar with the ovftool, you know you can specify an OVF/OVA from both a local resource as well as remote location such as a web server. Here is another example of deploying an OVF from a remote web server:

We can see that is pretty easy to deploy an OVF or OVA from within the ESXi Shell, but what about unattended installations such as ESXi kickstart? Yep, we can do that too! The easiest way is to compress the vmware-ovftool directory using tar command and then download it remotely using the wget command during the %firstboot stanza. I would also recommend placing your OVF/OVA images on a remote web server as well for centralize management and deployment.

Here is the sample code snippet that can be used in your kickstart:

# download ovftool tar to local storage
wget http://air.primp-industries.com/vmware-ovftool.tar.gz -O /vmfs/volumes/datastore1/vmware-ovftool.tar.gz

# extract ovftool content to /vmfs/volumes/datastore1
tar -xzvf /vmfs/volumes/datastore1/vmware-ovftool.tar.gz -C /vmfs/volumes/datastore1/

# deploy OVF from remote HTTP source
/vmfs/volumes/datastore1/vmware-ovftool/ovftool -dm=thin -ds=datastore1 "--net:access333=VM Network" "http://air.primp-industries.com/SLES-VM/SLES-VM.ovf" "vi://root:[email protected]"

# power on VM
vim-cmd vmsvc/power.on $(vim-cmd vmsvc/getallvms | grep "SLES-VM" | awk '{print $1}')

As you can see, virtually anything is possible ... even if you thought it was not earlier 🙂

vSphere Security Hardening Report Script for vSphere 5

by // 10 Comments

The much anticipated vSphere 5 Security Hardening Guide was just released last week by VMware and includes several new guidelines for the vSphere 5 platform. In addition to the new guidelines, you will also find that the old vSphere 4.x guideline identifiers (e.g. VMX00, COS00, VCENTER00) are no longer being used and have been replaced by a new set of identifiers. You might ask why the change? Though I can not provide any specifics, but rest assure this has been done for a very good reason. There is also a change in the security guidance levels, in the vSphere 4.x guide, you had enterprise, SSLF and DMZ and with the vSphere 5 guide, you now have profile1, profile2 and profile3 where profile1 provides the most secure guidelines. To get a list of all the guideline changes between the 4.1 and 5.0 Security Hardening Guide, take a look at this document here.

I too was impacted by these changes as it meant I had to add additional logic and split up certain guidelines to support both the old and new identifiers in my vSphere Security Hardening Script. One of the challenges I faced with the old identifiers and creating my vSphere Security Hardening Script is that a single ID could be applicable for several independent checks and this can make it difficult to troubleshoot. I am glad that each guideline is now an individual and unique ID which should also make it easier for users to interpret.

To help with your vSphere Security Hardening validation, I have updated my security hardening script to include the current public draft of the vSphere 5 Security Hardening Guide. You can download the script here.

Disclaimer: This script is not officially supported by VMware, please test this in a development environment before using on production systems.  

The script now supports both a vSphere 4.x environment as well as vSphere 5.0 environment. In addition to adding the new guideline checks and enhancing a few older ones, I have also included two additional checks that are not in Hardening Guide which is to verify an ESX(i) host or vCenter Server's SSL certificate expiry. I recently wrote an article on the topic here, but thought this would be a beneficial check to include in my vSphere Security Hardening Script. If you would like to see the verification of SSL certificate expiry in the official vSphere 5 Security Hardening Guide, please be sure to provide your feedback here.

Here is a sample output for the Security Hardening Report for a vSphere 5 environment using "profile2" check:
vmwarevSphereSecurityHardeningReport-SAMPLE.html

UPDATE (06/03/12): VMware just released the official vSphere 5 Security Hardening Guide this week and I have also updated my script to include all modifications. If there are any feedback/bug reports, please post them in the vSphere Security Hardening Report VMTN Group.

If you have any feedback/questions, please join the vSphere Security Hardening Report VMTN Group for further discussions.