How to add Intel NIC drivers to an ESXi 5.5 ISO

Modifying ESXi ISO images to include network drivers

Using new hardware with not-yet supported or unsupported drivers is often required when using consumer grade and/or desktop components. Most of the motherboards I have presented here on this blog (ASRock Z87 Extreme6, ASRock Z77 Pro4-M, Intel DQ77KB, Intel DQ77MK) have had unsupported network controllers.

There are ways to add support for a NIC after ESXi has been installed. However, to install ESXi from the beginning requires at least one supported network controller. Adding or updating a driver directly in the ESXi ISO solves this issue.

Tools required

To be able to perform the driver inclusion the following tools are needed:

When it comes to what driver to include I have to be honest to report that I have not been able to fully figure it out. Intel seems to have two lines of drivers for Linux, igb and e1000. from what I understand, the igb drivers are mostly for server NICs and the e1000 drivers for desktop NICs. Some desktop controllers use the igb driver though. Here is an excerpt from Intel’s website:

e1000e.x.x.x.tar.gz is designed to work with the Intel® 82563/6/7 Gigabit Ethernet PHY, 82571/2/3/4/7/8/9, 82583 Gigabit Ethernet Controller, and I217/I218 controllers under Linux*.  The latest version and earlier versions of this driver are available from SourceForge.

If your adapter/connection is not 82563, 82566, 82567, 82571, 82572, 82573, 82574, 82577, 82578, 82579, 82583 -based, you should use one of the following drivers:

– igb-x.x.x.tar.gz driver supports all Intel® 82575/6-, 82580-, I350-, or I210/1-based Gigabit Network Adapters/Connections.
– e1000-x.x.x.tar.gz driver supports all Intel® 8254x-based PCI and PCI-X Gigabit Network Adapters/Connections.

Furthermore, the drivers for ESXi needs to be recompiled from the above versions. The ASRock Z87 Extreme6 board, that will be used in this example, have the following two controllers:

  • Intel® Ethernet Connection I217-V, e1000e driver.
  • Intel® Ethernet Controller I211 Series, igb driver.

I will only demonstrate how to get the e1000e driver to work, simply because I have not yet found a newly compiled version of the igb driver. The newest e1000e driver I can find on the Internet is:

http://shell.peach.ne.jp/~aoyama/wordpress/download/net-e1000e-2.3.2.x86_64.vib

Credit goes to the following site:http://shell.peach.ne.jp/aoyama/archives/2907

Using the ESXi-Customizer

Here is how I set up the ESXi-Customizer

  1. Start the ESXi-Customizer
  2. Load the ESXi 5.5 ISO
  3. Load the net-e1000e-2.3.2.x86_64.vib driver package
  4. Uncheck UEFI bootable. (I have read both suggestions both for and against. Unchecked has worked well for me)
  5. Hit Run! to create the new ISO
  6. Burn the ISO to a disc or make a bootable USB out of it.

This is what the ESXi-Customizer looks like for me.

ESXi-Customizer

I hope everything works out. Either way, let me know in the comments below!

Moving an Ubuntu Server installation to a new partition scheme

My previous post covered how to clone an Ubuntu Server installation to a new drive. That method covered cloning between identical drives and identical partition schemes. However, I have grown out of space on one of the file servers which have the following layout:

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048  2146435071  1073216512   83  Linux
/dev/sda2      2146435072  2147483647      524288    5  Extended
/dev/sda5      2146437120  2147479551      521216   82  Linux swap

The issue now is that if increase the size of the drive, I can not grow the filesystem since the swap is at the end of the disk. Fine, I figured I could remove the swap, grow the sda1 partition and then add the swap at the end again. I booted up the VM to a Live CD, launched GParted and tried the operation. This failed with the following output:

resize2fs: /dev/sda: The combination of flex_bg and 
!resize_inode features is not supported by resize2fs

After some searching and new attempts with a stand alone Gparted Live CD I still got the same results. Therefor, I figured I could try to copy the installation to a completely new partition layout.

Process

Setup the new filesystem

Add the new (destination) drive and the old (source) drive to the VM and boot it to a Live CD, preferable with the same version as the source OS. Setup the new drive as you like it to be. Here is the layout of my new (sda) and old drive (sdb):

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048     8390655     4194304   82  Linux swap / Solaris
/dev/sda2         8390656  4294965247  2143287296   83  Linux
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048  2145386495  1072692224   83  Linux
/dev/sdb2      2145388542  2147481599     1046529    5  Extended
/dev/sdb5      2145388544  2147481599     1046528   82  Linux swap / Solaris

Copy the installation to the new partition

For this I use the following rsync command:

$ sudo rsync -ahvxP /mnt/old/* /mnt/new/

Time to wait…

Fix fstab on the new drive

Identify the UUIDs of the partition:

$ ll /dev/disk/by-uuid/

5de1...9831 -> ../../sda1
f038...185d -> ../../sda2

Remember, we changed the partition layout so make sure you pick the right ones. In this example, sda1 is swap and sda2 is the ext4 filesystem.
Change the UUID in fstab:

$ sudo nano /mnt/new/etc/fstab

Look for the following lines and change the old UUIDs to the new ones. Once again, the comments in the file is from initial installation, do not get confused of them.

# / was on /dev/sda1 during installation
UUID=f038...158d / ext4 discard,errors=remount-ro 0 1

# swap was on /dev/sda5 during installation
UUID=5de1...5831 none swap sw 0 0

Save (CTRL+O) and exit (CTRL+X) nano.

Setup GRUB on the new drive

This is the same process as in the previous post, only the mount points are slightly different this time:

$ sudo mount --bind /dev /mnt/new/dev
$ sudo mount --bind /dev/pts /mnt/new/dev/pts
$ sudo mount --bind /proc /mnt/new/proc
$ sudo mount --bind /sys /mnt/new/sys
$ sudo chroot /mnt/new

With the help of chroot, the grub tools will operate on the virtual drive rather than the live session. Run the following commands to re-/install the boot loader again.

# grub-install /dev/sda
# grub-install --recheck /dev/sda
# update-grub

Lets exit the chroot and unmount the directories:

# exit
$ sudo umount /mnt/new/dev/pts
$ sudo umount /mnt/new/dev
$ sudo umount /mnt/new/proc
$ sudo umount /mnt/new/sys
$ sudo umount /mnt/new

Cleanup and finalizing

Everything should be done now to boot into the OS with the new drive. Shutdown the VM, remove the old virtual drive from the VM and remove the virtual Live CD. Fire up the VM in a console and verify that it is booting correctly.

As a friendly reminder – now that the VM has been removed and re-added to the inventory it is removed from the list of automatically started virtual machines. If you use it, head over to the host configuration – Software – Virtual Machine

Cloning a virtual hard disk to a new ESXi datastore

One physical drive of my ESXi host is starting to act strange and after a couple of years I think it is a good idea to start migrating to a new drive. Unfortunately, I do not do this often enough to remember the process. Therefor, I intend to document it here and it could hopefully be of help to someone else.

Precondition

  • ESXi 5.1
  • Ubuntu Server 12.04 virtual machine on “Datastore A”
  • VM hard disk is thin provisioned

Goal

  • Move the VM to “Datastore B”
  • Reduce the used space of the VM on the new datastore

The VM was set up with a 1TB thin provisioned drive and the initial usage was up to 400GB. Later on I moved the majority of the used storage to a separate VM and the usage now is around 35GB. However, the previously used storage is not freed up and I intend to accomplish this by cloning the VM to a new virtual disk. As far as I know, there are other methods to free up space but I have not tried any of those yet. To be investigated…

Process

  1. Add new thin virtual hard disk to the VM of the same size on the new datastore
  2. Boot the VM to a cloning tool (I have used Acronis, but there are other free competent alternatives)
  3. Clone the old drive to the new one keeping the same partition setup
  4. Shut down the VM and copy the .vmx-file to the same folder as the .vmdk on the new datastore (created in step 1)
  5. Remove the VM from the inventory. Do not delete the files from the datastore
  6. Browse the new datastore, right click on the copied .vmx-file and select Add to inventory
  7. Edit the settings of the VM to remove the old virtual drive.
  8. Select a Ubuntu Live CD image (preferable the same version as the VM) for the virtual CD drive.
  9. Start the VM. vSphere will pop up a dialogue asking if the VM was moved or copied, select moved.
  10. Boot the VM to a Ubuntu Live CD to fix the mounting and grub
  11. Boot into the new VM

Let’s explain some steps in greater detail.

4. Copy the VMX file

If this is the initial state:

DatastoreA/VM/VM.vmdk
DatastoreA/VM/VM.vmx

After adding a second drive, VM_B.vmdk, on the other datastore (step 1), cloning VM.vmdk to VM_B.vmdk (step 3) and copying the VM.vmx to the VM-folder on datastoreB (step 4), the layout would be the following:

DatastoreA/VM/VM.vmdk
DatastoreA/VM/VM.vmx

DatastoreB/VM/VM_B.vmdk
DatastoreA/VM/VM.vmx

10. Boot the VM to a Ubuntu Live CD to fix mounts and grub

This section is heavily dependent on the guest OS. Ubuntu 12.04 uses UUID’s to mount drives and to decide which drive to boot from. The new virtual drive will have a different UUID than the original drive and will therefor not be able to boot the OS. This is where the Live CD comes in.

Once inside the Live CD, launch a terminal and orientate yourself. To identify the UUIDs of the partition use:

$ ll /dev/disk/by-uuid/

5de1...9831 -> ../../sda1
f038...185d -> ../../sda2

Next, let’s mount the drive:

$ sudo mount /dev/sdXY /mnt

where X is the drive letter and Y is the root partition.(If you have some exclusive partitioning setup you might need to mount the other partitions to be able to follow these steps. But then again, you probably know what you are doing anyway)

Change the UUID in fstab:
$ sudo nano /mnt/etc/fstab
Look for the following lines and change the old UUIDs to the new ones.

# / was on /dev/sda2 during installation
UUID=f038...158d / ext4 discard,errors=remount-ro 0 1

# swap was on /dev/sda1 during installation
UUID=5de1...5831 none swap sw 0 0

Next up is changing the grub device mapping. The following steps have I borrowed from HowToUbuntu.org (How to repair, restore of reinstall Grub).

$ sudo mount --bind /dev /mnt/dev
$ sudo mount --bind /dev/pts /mnt/dev/pts
$ sudo mount --bind /proc /mnt/proc
$ sudo mount --bind /sys /mnt/sys
$ sudo chroot /mnt

With the help of chroot, the grub tools will operate on the virtual drive rather than the live OS. Run the following commands to re-/install the boot loader again.

# grub-install /dev/sda
# grub-install --recheck /dev/sda
# update-grub

Lets exit the chroot and unmount the directories:

# exit
$ sudo umount /mnt/dev/pts
$ sudo umount /mnt/dev
$ sudo umount /mnt/proc
$ sudo umount /mnt/sys
$ sudo umount /mnt

Now we should be all set. Shut down the VM, remove the virtual Live CD and boot up the new VM.