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!

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.

VM Provisioning on Datastore Clusters in vSphere 5

by // 24 Comments

Last year I wrote an article called Automating Storage DRS & Datastore Cluster Management in vSphere 5 and I provided a pretty comprehensive vSphere SDK for Perl script to help administrators automate Storage DRS configurations. These past few months I have noticed an increase in interest on the VMTN developer forums relating to Storage DRS. Majority of the questions has been related to which vSphere API methods to use and how to use these methods for cloning VMs to datastore clusters.

If you have cloned a VM before, the underlying vSphere API method being used is the CloneVM_Task(), but when cloning a VM to a datastore cluster, a different API must be used.

In vSphere 5, VMware introduced several new API methods in the StorageResourceManager and the two specific ones relating to provisioning VMs are RecommendDatastores() and ApplyStorageDrsRecommendation_Task(). The process to clone a VM to a datastore cluster is a two step process:

  1. Call RecommendDatastores() which accepts very similar input as the CloneVM_Task(). In addition, you need to specify the datastore cluster also known as a Storage Pod in the vSphere API as well as the "type" (create, clone, relocate, reconfigure), in this example we will be performing a clone operation. This method will then generate a recommendation on where to place the VM which is based on the SDRS placement engine. No provisioning will occur at this point, just a placement recommendation.
  2. To perform the actual provision of the VM, you will need to call ApplyStorageDrsRecommendation_Task() which accepts a recommendation ID that was generated from the first step. Once the recommendation is applied, the provisioning of the VM will start just like it did when you called the CloneVM_Task().

Note: The RecommendDatastores() will return multiple recommendations, the best one will be first entry in the array. This is the same algorithm used when performing this same operation in the vSphere Client, it also selects the first recommendation.

Now that we understand how the APIs work, let's take a look at how we can leverage this in a script for some automation! Here is a simple vSphere SDK for Perl script called datastoreClusterVMProvisioning.pl which allows you to clone an existing VM onto a datastore cluster. You will need a system that has vCLI 5.0 installed or you can use VMware vMA 5 to run the script. You will also need to connect to a vCenter Server 5 for all SDRS operations.

The script requires 4 input parameters:

  • vmname - Name of the VM you wish to clone from
  • clonename - Name of the cloned VM
  • vmfolder - Name of a vCenter folder
  • datastorecluster - Name of a datastore cluster

Here is a screenshot of cloning an existing VM onto a datastore cluster:

The script is pretty straight forward and it can easily be adapted to include other configurations as required in your own environment.

Hopefully this gives you a better idea on how to leverage the new provisioning APIs for Storage DRS and start automating your VM deployments onto datastore clusters and get the benefits Storage DRS in your vSphere environment.