Preparing Images for Bare Metal nodes using OpenStack Cloud: Bare-metal provisioning, Part 3

http://www.mirantis.com/blog/baremetal-provisioning-part3-images-preparation/

Recently we began a series of blog posts on
OpenStack provisioning bare-metal instances (see:
Beyond virtual machines and hypervisors and
Placement control and multi-tenancy isolation). While installing VMs is relatively easy, as they support common image formats like OVF and qcow2, bare-metal servers are not always that simple.

This article describes how to prepare images for bare-metal nodes. In the case of Linux-based images, this process should work just fine because the generic kernel by default includes general hardware types and features. However, Windows-based images require
special attention; the problem is that, once installed, Windows OS only works with the same hardware/architecture it was created for. Thus, images should be prepared on the same hardware nodes you are planning to use them on.

Image preparation overview

The simplest way to prepare images for bare metal consists of three general steps:

Basic preparations: Establishing a connection to the bare-metal server and hardware management console.
Installation of the OS on the remote node using the CD-ROM with the installation media, which is redirected using the hardware management console.
Rebooting the system and booting from LiveCD in order to create the installed system’s image using the standard Unix utility
dd and sending the image to the remote host (e.g., a host with the Glance client installed) with
netcat.

Details

First you need an access to a bare-metal node. In our case, we had a Dell 6105 server with an IPMI-interface.

The IPMI-interface allows you to interact with a remote host through a Java applet (JViewer in Dell’s case). Aside from the screen redirection and keyboard forwarding, it has a very important facility—redirection of the ISO image or CD-ROM to the server
side. In other words, the hardware management console allows us to use a local CD-ROM on the remote end.

To make a node boot from CD-ROM you might need to change the boot priority in the BIOS.

Once that is done, the server should be rebooted through the IPMI-interface and you can begin the installation process. The installation process will typically take longer, since the installation image physically resides on the operator’s workstation and
depends on the capacity of the data channel.

After a successful installation of the system, the configuration should be changed. In the case of Windows Server 2008 there are some tricks that I will cover below.

Next, we need to boot from LiveCD. The boot process is similar to the process described above for the beginning of the installation. We used Ubuntu. Preconfigure the network in /etc/network/interfaces to
send image data to the remote server through

netcat

, then get the available hard drives with the command

# fdisk -l

1	# fdisk -l

and make sure that they are not mounted

# df

1

# df

Now you can proceed directly to image creation. On the client side execute:

# nc -l 3333 > name_of_your_snapshot.img

1	# nc -l 3333 > name_of_your_snapshot.img

netcat

will be waiting for an incoming connection on a specified port. At the same time, on the remote host execute:

# dd if=/dev/sda conv=sync,noerror bs=8M count=5000 | nc 192.168.11.1 3333

1	# dd if=/dev/sda conv=sync,noerror bs=8M count=5000 | nc 192.168.11.1 3333

where:

/dev/sda is a partition in the installed system,
bs is the size of the block,
count is the number of blocks, and
192.168.11.1 3333 is the ip-address and port of the client.

Grab 5,000 blocks, 8 megabytes each, from the beginning of the
sda disk (40 GBs in total, the size of the Windows installation) and send it with

netcat

to the remote server.

When everything is completed successfully you get:

524288+0 records in
524288+0 records out
268435456 bytes transferred in 231.665702 secs (1158719 bytes/sec)

1 2 3

524288+0 records in 524288+0 records out 268435456 bytes transferred in 231.665702 secs (1158719 bytes/sec)

The image has been created and transferred to the local host.

Difficulties we faced

There were three ’gotchas’ we encountered; we’ve listed them in the hope you’ll be able to use this to avoid these problems.

1. Dell’s JViewer

First, when using JViewer, we had the following problems:

It duplicated characters when typing, making it impossible to enter any passwords or logins.
It was unable to process Latin character input.

These problems were solved by creating a virtual machine on the server physically allocated nearby with bare metal and working with IPMI through that. It could also have been related to the installed version of Java, which we cured by installing JRE version
6.

2. Location of the MBR boot sector

The second issues was during the installation of Windows family systems. We encountered a possible problem associated with the location of the MBR boot sector.

Windows allows you to work with hard disk partitions of approximately 2 terabytes. If the hard disk or RAID-array assigned for installation is larger than 2 terabytes, then the disk will be divided into logical sectors smaller than the maximum allowed.

In this case the system partition and MBR will be allocated on a different logical disk than the installed system, and nowhere else. This makes the image of the system made from /dev/sda/ unusable since
the system partition and MBR are on /dev/sdb/.

Thus, you should make sure to install Windows on a partition less than 2 terabytes.

3. Problem with Windows firewall

The third glitch we faced during the testing of images was related to Windows Server 2008’s firewall. The image launched through OpenStack wasn’t accessible through the network, but we solved it by switching off the firewall at the command prompt:

# netsh advfirewall set allprofiles state off

1	# netsh advfirewall set allprofiles state off