Yellow Bricks

by Duncan Epping

esxi

Installing drivers during a scripted install of ESXi

· ·

As you hopefully have read I have been busy over the last weeks with a new project. This project is all about enabling migrations to ESXi. I wrote two articles for the ESXi Chronicles blog of which the first article describes the scripted install procedure and the seconds gives some additional advanced examples of what is possible in these scripts. Based on that article I started receiving some questions from the field and last week I had a conference call with a customer who had issues “injecting” a driver into ESXi during the install. Normally installing a driver is done by using a simple “esxupdate” command and a reboot, but in this case however the situation was slightly different and let me explain the problem first.

This customer implemented a script that would run during the %firstboot section. The name of the section already explains what it is, this section will run after the reboot of the scripted install has been completed. The way this works is that ESXi creates a script in /etc/vmware/init/init.d with the prefix 999. This script will run as the last script during the boot and is generally used to configure the host. After a final reboot this script is automatically deleted and the host is ready to be added to vCenter.

The challenge however that this customer was facing is that it was using a Xsigo network environment. In this scenario a server that would need to be reinstalled would get a temporary network configuration that would only work during the first boot. Meaning that before this %firstboot section would even run the original network configuration would be restored. The problem with that however is that the original network configuration requires the drivers to be installed before it can be used. In other words, after the reboot done by the installer you will not be able to access the network unless you have loaded the drivers. This rules out downloading the drivers during the %firstboot section. Now how do we solve this?

The scripted installation has multiple sections that can contain your commands. The first section is called %post. The ESXi setup guide describes this section as follows:

Executes the specified script after package installation has been completed. If you specify multiple %post sections, they are executed in the order they appear in the installation script.

This means that in the case of this customer we will be able to use this section to download any driver package required with for instance “wget” and that is what I did. I issued the command below during the %post section and rebooted the server.

wget http://192.168.1.100/xsigo.zip

The problem however was that the package wasn’t persisted after a reboot which brought me back to right where I began, without a network after the restart. Than I figured that during the install a local datastore is created and I could use that as persistent storage. So I issued the following command in the %post section of the script:

wget http://192.168.1.100/xsigo.zip -O /vmfs/volumes/datastore1/xsigo.zip

I rebooted the installer and checked after the install if the driver bundle was there or not, and yes it was. The only thing left to do was to install the driver in the %fistboot section. This by itself is a fairly simple task:

esxupdate --bundle=/vmfs/volumes/datastore1/xsigo.zip update

As the host will need to reboot before the drivers are loaded I also added a “reboot” command at the end of to the “%firstboot” section. This ensures the drivers are loaded and the network is accessible.

I guess this demonstrates how easy a solution can be. When I first started looking into this issue and started brainstorming I was making things way too complex. By using the standard capabilities of the scripted install mechanism and a simple “wget” command you can do almost everything you need to do during the install. This also removes the need to fiddle around with injecting drivers straight into the ISO itself.

Go ESXi 🙂

What have you’ve been up to?

· ·

I got a couple of questions around what I have been up to lately as some noticed there was a slight decrease in volume from a blogging perspective on yellow-bricks. (from 4 articles per week to 2-3 article per week) Well I have been reading up on my new role but on top of that also started blogging for the ESXi Chronicles blog (add it to your RSS reader) and created a VMware Storage centric twitter account. (Follow me if you want to keep up to date on VMware storage initiatives!) The things that I’ve worked on the last couple of weeks:

  • VMware ESXi: Planning, implementation and security
    The week before VMware Partner Exchange I decided that it was time to start brushing up my ESXi knowledge. I usually dig up all the manuals and presentations I can find and start from there. This time I took a different approach however, I bought a book. The book is titled “VMware ESXi: Planning, Implementation, and Security” and is authored by a true VMTN Community hero, Dave Mishchenko.
  • Scripted install with ESXi
    Now you can kick off the automated install of your ESXi server. But wait, you probably want to see what script I used? That is what I figured, here is the script I wrote to automatically install and configure the ESXi host, it is just a simple script that I used and tested in my lab with the main purpose of showing what is possible with ESXi today. The configuration of the server will run after the first boot. I have added several “comment lines” to explain what I am doing and why.
  • Adopting ESXi, now is the time!
    Within the virtualization community we have been seeing more and more people adopting ESXi. Not only adopting it but also actively evangelizing the use of ESXi over ESX classic. The main argument being of course the reduction in operational effort involved with maintaining the platform. Last week two excellent articles were published. The first article was by Bob Plankers of LoneSysAdmin.net fame. Bob wrote an excellent article countering all often heard complaints about ESXi.

I also wrote my first KB article which discusses the impact of CPU/Memory limits with help from someone from the the GSS team. You would expect that a KB article describing the impact already existed but surprisingly enough it did not. Hence the reason I felt an official statement could prevent some of the issues we see in the field on a daily basis.

Of course that’s not it, I am working on multiple other projects which I cannot discuss yet unfortunately and participated in the VCDX Defenses at PEX. One of the things I can reveal though is that Frank and I are make plans for a volume 2 of the HA/DRS Tech Deepdive and that the sales is still going strong, thanks everyone for your help/support! (No, there will not be an e-book unfortunately, the amount of time/reformatting required did not fit our current schedule.) Keep those reviews and pictures coming though.

RT: VMware Event – London – 8th Oct – Not to be missed!

· ·

I was just talking to Mr Alan Renouf and it appears that there are a couple of free slots left at the API/PowerCLI event that VMware has organized in coöperation with Alan on the 8th of October in London.

If you are in London on the 8th October 2010 then you could be in for a treat, VMware are arranging a fantastic event, well worth the visit and best of all its free !

The event is called: Managing vSphere in large environments using APIs and PowerCLI

There are limited spaces available so act now or you will miss out, some of the most fantastic minds of VMware will be gracing London with their presence before heading out to VMworld Copenhagen.

Think of this as a taster of the kind of things you can expect from Technology Exchange, the contents are listed below, I would recommend this to any VMware admins who are managing large implementations of vCenter, there will be some great detail in these sessions.

If you would like to attend please send an email to PowerCLIEvent@virtu-al.net with your name and company, this will strictly be on a first come first serve basis as there are limited numbers.

Exploring VMware APIs

Speaker: Preetham Gopalaswamy

vSphere APIs for Performance Monitoring

Speaker: Balaji Parimi, Ravi Soundararajan

Of course Alan really focussed on the API part of the event, but that is not all there is. If you thought my esxtop page was useful, make sure to attend this event as this is the best part of the day in my opinion:

Advanced performance troubleshooting using esxtop

Level: Advanced

Length: 60 minutes

This talk will teach you how to spot tricky performance issues using the various counters in esxtop.

Speaker: Krishna Raj Raja, Staff Engineer, Performance Team

If you are in the UK and can’t make it to VMworld, this is your chance to catch some of the top experts and get to know the API and esxtop inside out!

Enable SSH on ESXi 4.1

· ·

As, to my surprise, I still daily have 300/400 unique views on my article about how to enable SSH on ESXi 3.x I figured people would be interested in knowing how to enable it on ESXi 4.1. SSH is part of the TSM (Tech Support Mode) functionality. There are two different kind of Tech Support Modes:

  1. Local Tech Support (Commandline access)
  2. Remote Tech Support (SSH)

Enabling either of the two is really simple:

  • Open the ESXi console
  • Login(F2) and go to “Troubleshooting Options“
  • Now you will see options called “Tech Support”, hit “enter” on either Remote Tech Support (SSH) or Local Tech Support

You could of course also enable it through the vSphere Client:

  • Select the host and click the Configuration tab.
  • Click Security profile > Properties.
  • Click Local Tech Support or Remote Tech Support (SSH) and click Options.
  • Choose the desired startup policy and click Start, then click OK.
  • Verify that the daemon selected in step 3 shows as running in the Services Properties window.