Search Results for: kickstart

How to Deploy ESXi 5 Using Razor & Puppet

05.25.2012 by William Lam // 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

05.21.2012 by William Lam // 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 🙂

Removing Previous Local Datastore Label for Reinstall in ESXi 5

04.24.2012 by William Lam // 18 Comments

If you reinstall ESXi 5 on system that had a previous copy, one thing you might have noticed is the local VMFS datastore label is preserved. This is also true if you perform an unattended installation using kickstart and specifying the overwritevmfs parameter, a new VMFS volume is created but it still uses the old label. This can cause some issues for scripted installs where you decide to rename the local datastore from the expected default "datastore1" label.

UPDATE (12/21) - This issue has been resolved in the latest release of ESXi 5.0 Update 2, you can refer to the release notes for more details on other updates and fixes.

Though it is actually pretty easy to get around this problem by deleting the VMFS partition prior to starting the new ESXi installation. Below are three methods depending on the installation option you have chosen. Please be absolutely sure about the VMFS volume prior to deleting the partition.

Method 1 - While you still have login access to previous ESXi install

If you still have access to the system before the re-install, you can delete the VMFS partition before rebooting and starting the installation (ISO or kickstart). You will first need to identify the device that is backing your local datastore, you can use the following ESXCLI command which will provide a mapping of your datastore to device.

You will need to make a note of the "Device Name" which can be a naa.* or mpx.* depending on how your ESXi host identifies the disk. You should also make a note of the partition number for the VMFS volume which we will also confirm in the next step. Using the partedUtil we can check the partitions found on the disk and we can confirm that partition 3 is being used for VMFS. Using the "getptbl" option and specifying the full path to the disk which is under /vmfs/devices/disks/naa.* we can retrieve the partition info as shown below.

Now we just need to delete this partition which will wipe the VMFS headers which includes the datastore label. We can do this by using partedUtil and using the "delete" option which will require the full path to the disk in our previous step.

You can now reinstall ESXi and it will use "datastore1" as it's default VMFS label.

Note: The disk that contains the local ESXi 5 install will always have VMFS as the 3rd partition, where as other VMFS volumes will only have a single partition.

Method 2 - During manual installation using ESXi 5 ISO

When you boot up the ISO, you are brought to the "Welcome to VMware ESXi 5.0.0 Installation" page, you will need to login to ESXi Shell by pressing ALT+F1. The username will be root and there is no password, just hit enter. Just like in Method 1, you will need to identify the device for your local datastore but instead of using esxcli, you will need to use localcli as hostd is currently not running.

Here is a screenshot of the identifying the local datatstore device and deleting the VMFS partition:

You can now jump back to the installer by pressing ALT+F2 and continuing with the reinstall and it will use "datastore1" as it's default VMFS label.

Method 3 - Kickstart Installation

If you wish to ensure that the default "datastore1" label is always available for scripted installs, you can using the following snippet in your %pre section of your kickstart. This will search for all disks under /vmfs/devices/disks and find the deivce that is backing a local ESXi installation and delete it's VMFS partition prior to starting the installation.

for DISK in $(ls /vmfs/devices/disks | grep -v vml);
do
        DISK_PATH=/vmfs/devices/disks/${DISK}
        VMFS_PARTITION_ID=$(partedUtil getptbl ${DISK_PATH} | grep vmfs | awk '{print $1}')
        if [[ ! -z ${VMFS_PARTITION_ID} ]] && [[ ${VMFS_PARTITION_ID} -eq 3 ]]; then
                partedUtil delete ${DISK_PATH} 3
        fi
done

Note: To be extra cautious, you should also consider disabling any additional remote LUNs that can be seen during the installation using the trick found here.