Installing ESXi with Razor • Technodrone

This is part #6 of the Razor series. In the last post we looked at what lies within the installer. In this post we will go more into detail of how exactly the installation process works. Fort his post we will run through the deployment of an ESXi host.

Since there has been some time from the last part of this series I will recap what you should have in your environment.

We have a repository named ESXi_5_1 for our ESXi installation.

We have a policy named ESXi51 defined that will deploy ESXi to the node.

And we have a tag (which is what the policy above uses) named Test_tag used to classify the node.
(this is the minimum that will allow us to install ESXi - 2vCPU’s and 4GB RAM)

We then power on a node. It boots up, receives an IP from the Razor server and then continues to boot to the microkernel.

In the meantime on our Razor server we see that a new node node3 has been recognized.

razor nodes

Looking at the details for that node - we will initially only see the following information:

mac address
uuid
log location

razor nodes node3

Looking at the log for the node:

razor nodes node3 log

When the node is matched against a policy - it will reboot. This can be seen in two places.

Looking at the node information again - here you will there is far more information about the hardware. This is because the microkernel has now reported back to Razor with all the information.

razor nodes node3

You can see that the node was matched against a policy.

The tag was also correctly recognized.

Looking at the log you will see additional entries. The 3rd entry shows that the node is now bound to the ESXi_5_1 policy. The 4th entry reports that the node has now rebooted - as a result of the policy.

razor nodes node3 log

Back to the node. We now see the node connecting to the ESXi repo

Looking at the node log again on the Razor server - we will see the process of the installer.

And from the node’s perspective.

There are two things I would like to point out here - and the information here is current only for the time of this article - because the product is constantly evolving - things could change.

Taking another look at the nodes logs we can see the following:

razor nodes node3 log

The first entry gives you the URL of the kickstart file that will be used. The contents of that file will show that the password is already populated (encrypted of course) and that there is a API call to report that the kickstart is finished. This of course can be accessed through the API with a web browser .

There are no network settings and no hostname settings defined in the kickstart. This is not supported/functioning in the current release.

The second thing you might notice in the log is that the second entry will already report stage_done almost immediately after the ks.cfg file is retrieved. In reality the process is far from being completed - it has only really started - because a good part of the ESXi installation is done in the %firstboot section.

The reason that this is done is because - the node needs to boot from its local disk to complete the installation (%firstboot), if not it will go into an infinite loop and never complete the next phase.

So even if you log says that the installation has finished - it will still continue through the installation process.

As a side note - there is a problem using this method when installing ESXi 5.0, wget on that busybox version does not know how to exit properly when retrieving an empty page (more info can be found here).

Here - in theory - you could pass the work over to an external broker - but currently there is no working example for ESXi.

This is where Razor’s job finishes with the node - but there are several points that are missing - two of them for me were critical.

This method does not support static IP addresses. I do not know of many people who deploy their hosts with dynamic IP’s. I certainly do not.
There is no support for configuring the hostname of the node - which means this needs to be taken care of in another way.

I will say that I have found a way to circumvent both of these problems - but that will come in an additional post.

I hope you have managed to stay with me until now - and managed to digest most of this. It is a lengthy process but I have tried to be as detailed as possible to explain the process better.

The next part will provide a run through of installing a Linux node and passing that over to Puppet for configuration.