Cloud computing gets a lot more personal

I’ve just bought the biggest smartphone that I could find and have been using it for the past couple of weeks with great results. I’ve had both admiring looks and a few sniggers due to its size. It’s kind of a cross between a tablet and a phone.

I’ve never put it up to my ear however, as I think it’s a bit too much, I use a hands free kit instead. I don’t really want to be seen looking like this now do I?

At the moment I’m really happy with my purchase because it means that not only do I have a new phone, I now have a phone with a big screen and cool functionality. One of the reasons I decided to go for such a hybrid is so that I can read e-books on it without squinting to see the text.

It also means that I do not have to take my iPad around with me when I travel, which means one less device to manage. So how is this related to the blog post title you may ask? Well, I wanted to take this a little further to see if I can use only my mobile phone as my primary computing device. I say primary but this little guy still needs help from his friends in the cloud. So I thought wouldn’t it be cool if I could hook up my phone to an external monitor, connect some peripherals and see what happens…

Well this is the result:

The image above shows my Galaxy Note connected to a 24″ monitor using a HDMI cable for full 1080p resolution. I’ve connected my Apple Bluetooth keyboard and Magic Mouse to it, and also installed VMware View Client for Android. It’s running a VMware View session using PCoIP over a WIFI connection to my View desktop in one of VMware’s datacentres. How awesome is that?

So why would you want to do this? Well, for one thing it’s pretty cool, the simplicity and usability is amazing and it feels quite natural. Why wouldn’t you use a small personal device such as a mobile phone as a thin client for accessing cloud resources such as a remote desktop hosted on VMware View?

It’s simple yet solves quite a few issues regarding end user access points. We’ve all seen those reports and calculators that justify thin client devices over traditional fat PCs. I’m not an EUC/VDI guy so I just typed “cost of thin client” into Google and went to http://www.2x.com/whitepapers/savings-thin-client-computing/ to take a look at the report.

A report by Bloor Research states that moving over to thin client computing could save costs of up to 70%. I’m going to be a little lazy and quote directly from the web page:

*1 Explanation of savings on administration

These were calculated at $1000 per PC. Many research studies indicate that the amount is between $800 and $1,700 per year. Beyond day-to-day maintenance of installation of patches, software upgrades, etc, there is also the 3 year upgrade cycle which requires an administrator to move all the data and profiles to the new PC. On average this will cost $300 per PC, making for an additional cost of $50 per year (over a 6 year period). Since administration is simplified, an enterprise will require fewer IT staff to perform the same number functions. This means lower training costs and fewer salaries to pay. Bloor Research estimates that the number of helpdesk staff needed can be reduced typically by 50% and often by 75%.

*2 Explanation of savings on client hardware

These were calculated to be $208 per PC per year. You can get an adequate thin client for $250, in contrast with the average price for a PC of about $750 – this results in a saving of $500. Since PC hardware has to be upgraded approximately every 3 years as opposed to a thin client which only needs to be replaced every 6 years, the savings increase to $1250 over a span of 6 years ($1500 spent on 2 PCs as opposed to $250 on 1 thin client device). This amount is then divided by 6 to calculate a yearly saving. If you are using existing PCs instead of thin clients, the hardware savings can still be applied because you would be extending the life span of the converted computers. Furthermore, the MTBF of a thin client device is higher and it uses far less energy.

*3 Explanation of extra server hardware costs

These were calculated at $50 per user. Because all processing is done on the server, when using thin clients you will need to buy additional servers to act as terminal servers. On average 30 users will need a dual processor server with 4 gigs of RAM and SCSI hard disks. A brand name server should cost around $4,500 and will depreciate on average in 3 years (in reality you can use them for longer than that).

So that’s a 70% saving according to Bloor Research for just using thin clients over traditional PCs. But hang on, what about further savings? How about ditching the thin client concept altogether and allow users to use their smartphones?

With the popularity of BYOD (bring your own mobile device: expense the monthly costs for calls and line rental) programs, could be the coup de grâce for thin clients everywhere. Most smartphones nowadays are a lot more powerful than the average thin client and for the average office application and e-mail worker, a smartphone may be just the right device to use.

Some other benefits I see since using my smartphone to access my View Desktop:

  • It’s my device, I look after it, I clean it, I never spill coffee on it. No one else can touch it. It’s my personal device so I sure as hell am going to take care of it. Do you ever clean your thin client or work computer?
  • I can take it with me when I go to make coffee, or to the printer, or to a meeting. My office and most of my customer’s offices have WIFI everywhere, so my View session does not disconnect. And when I return to my desk, I just plug the HDMI cable back in and everything is still there. No work is lost as everything just resumes.
  • I can take my device anywhere, it’s a smartphone, it’s got my e-mail, calendar, messages, contacts, Twitter and a web browser. I can use it to communicate when I’m out of the office, I can continue working when I’m out and about. And when I return to my desk or home, I can just reconnect it to an external monitor and paired input devices and my session is still there and I can continue where I left off.
  • It’s secure, no-one is going to attempt to log into my session if there’s nothing to log in to! I don’t even have to ‘lock my computer’ anymore, as it’s safely secured in my jacket pocket.
  • Oh and it can still make and receive calls.

Coupled with VMware Horizon Mobile http://www.vmware.com/products/mobile/overview.html, I think we are onto a sure winner. Click on the image below to watch a short video of what Horizon Mobile is all about.

Let’s just see if this little idea kicks off and makes 2012 the year of VDI… again.

Eye candy below… Comments always welcome, video guide to follow.

            

Uploading vShield Manager 5.0.1 to vCloud Director as a vApp Template

A quick post on how to enable the import of vShield Manager 5.0.1 OVA as a vApp Template into vCloud Director. This will allow you to spin up vCloud Director labs inside of vCloud Director for some crazy inception action.

Note: that this method can be used for other appliances.

As you know if you downloaded vShield Manager from VMware, the file format would be in OVA format, which is not compatible with vCloud Director.

This post goes through some of the steps required to

  • Convert the OVA to OVF
  • Edit the OVF to remove vCloud Director unsupported features (vmw:ExtraConfig)
  • Create a new manifest file with the new SHA-1 hash

What you will need

  1. VMware OVF Tool available to download here http://www.vmware.com/technical-resources/virtualization-topics/virtual-appliances/ovf.
  2. Notepad++ available to download here http://notepad-plus-plus.org/download/v5.9.8.html.
  3. A SHA-1 generator available online here http://hash.online-convert.com/sha1-generator.

Converting OVA to OVF

Once you’ve downloaded the VMware-vShield-Manager-5.0.1-638924.ova file, use the VMWare OVFTool to convert it to OVF format.

Open up the command prompt and run the following, assuming that the ova file is saved in C:\Users\Hugo Phan\Downloads\

C:\Program Files\VMware\VMware OVF Tool>ovftool.exe “c:\users\Hugo Phan\Downloads\VMware-vShield-Manager-5.0.1-638924.ova” “C:\Users\Hugo Phan\Downloads\VMware-vShield-Manager-5.0.1-638924.ovf”

The following files will then be extracted within the directory

VMware-vShield-Manager-5.0.1-638924.mf

VMware-vShield-Manager-5.0.1-638924.ovf

VMware-vShield-Manager-5.0.1-638924-disk1.vmdk

Editing the OVF file to be compatible with vCloud Director

If you now tried to use the current .ovf file to upload vShield Manager into VCD as a vApp Template, you will see the following error:

We need to remove the vmw:ExtraConfig elements from the .ovf file. To do this follow these instructions:

  1. Open the VMware-vShield-Manager-5.0.1-638924.ovf file in Notepad++ or your preferred text editor that does not add carriage returns.
  2. Search for the three vmw:ExtraConfig lines and remove them from the file.

  3. Save your file and exit Notepad++.
  4. Now visit http://hash.online-convert.com/sha1-generator and upload the VMware-vShield-Manager-5.0.1-638924.ovf file and click on the Calculate Hash button.

  5. When you see the message You hash has been successfully created, copy the top lower case hex hash and open up the VMware-vShield-Manager-5.0.1-638924.mf file in Notepad++

  6. Replace the current hash for VMware-vShield-Manager-5.0.1-638924.ovf with the new one.

  7. Save the file.
  8. Now you can successfully upload the new VMware-vShield-Manager-5.0.1-638924.ovf to vCloud Director without the error occurring.

Creating (a better) vSphere 5 ESXi embedded USB Stick (HP)

In a previous post I blogged about creating a vanilla vSphere 5 ESXi USB drive using the VMware .iso file from VMware. This post shows how to create one using the HP version of vSphere ESXi (5.0_Oct_2011_ESXi_HD-USB-SDImgeInstlr_Z7550-00253.iso).

Note: (You can use any vendor customized vSphere ESXi .iso file: VMware, Dell and IBM).

The HP version comes pre-installed with all the HP CIM providers which work very well with HP servers, including the HP MicroServer. Using the HP version gives you the more details in the Hardware Status tab.

I’m going to be using a different method, recommended by Will Rodbard (thanks Will), who is a colleague of mine at VMware, you can see his comments from the previous post. In summary the steps are:

  1. Find and download the following tools:

    HPUSBFW & UNETBOOTIN

  2. Run the HPUSBFW tool, click on the USB drive, select ‘Fat32′ and click Format
  3. Run UNETBOOTIN, select Diskimage and browse to the ESXi 5 ISO file
  4. Select the USB drive you have just formatted and click OK
  5. If you want to make more USB keys for more servers, then now is the time to create .IMG files using WinImage, then you can basically clone the image of the USB key to more USB keys. Or if you don’t wish to use WinImage then just perform steps 1 to 4 again.

Once completed your USB drive will boot into the ESXi 5 installer. Once booted, install the ESXi 5 Hypervisor to the USB drive (overwriting the installer). This will then leave you with the installed ESXi Hypervisor on the USB.

Note that using this method creates a brand new bootable USB key for use in a new installation of vSphere ESXi. You will have to go through the process of installing ESXi onto the USB key, or another disk or LUN on the target server. If you want a USB key that is already installed with ESXi which saves you from going through the installation wizard, you can use the other method in this post.

[Aside]

I coincidently left an older USB key in my laptop and booted. Here’s a picture of my Macbook Pro running vSphere ESXi, and it all works by the way, including networking!

Configure NFS Storage on the VMware vCenter Server Appliance

This post highlights some best practices on the management of the vCSA log and core files. VMware recommends that these files are stored on an NFS share external to the vCSA due to the possibility of the default log and core locations filling up.

When this happens, vCenter services will be impacted.

For more information about the vCSA, please see the resources listed here https://vmwire.com/vmware-vcenter-server-virtual-appliance-vcsa/.

There may be trouble ahead

This screenshot shows what happens when this is not done, the partitions for /storage/core will fill up over time and will impact the availability of vCenter Server.

Figure 1 – Local core storage full!

Configuring NFS storage on the vCSA

You can add the NFS shares for the log and core files by logging into the VMware Studio management interface of the vCSA, normally https://<vcsa>:5480.

The default username and password is root | vmware.

Click on the vCenter Server tab, and then click on Storage.

Figure 2 – Configuring NFS storage on the vCSA

Using the correct syntax for the NFS storage

The correct syntax for adding the storage is

<NFS_Server>:<NFS_Export>

So if my NFS_Server is 192.168.200.21 and my NFS_Export is /mnt/vg01/vcsa_core/vcsa_core/, I would enter the following in the box for NFS share for core files:

192.168.200.21:/mnt/vg01/vcsa_core/vcsa_core/

Make sure that the NFS export on the NFS Server is configured with a UID/GID mapping of no_root_squash. For example, use the command on the NFS server:

exportfs -vo rw,no_root_squash,sync :/mnt/vg01/vcsa_core/vcsa_core/

Once done, click on Test Settings to verify that the vCSA can successfully store files to the specified NFS shares, then click on Save Settings, then restart the vCSA.

Browsing to the NFS storage

You can also see what is created in the NFS share if you listed the contents of the core files share.

Figure 3 – Core logs

You can also see what is created in the NFS share if you listed the contents of the log files share. The screenshots below show the directory structure on the NFS server. On the vCSA the directories are mounted at /storage.

Figure 4 – All other Logs

Adding sysprep packages to the VMware vCenter Server Virtual Appliance

The VMware vCenter Server Appliance (vCSA) is a Linux version of the vCenter Server, this post discusses the placement of the System Preparation tools (sysprep) packages within the vCSA and how to make the contents of the DEPLOY.CAB file available. Once configured, it is possible to use Guest Operating System Customizations with the vCSA.

My previous posts provide further detail around the features and benefits, feature parity with the Windows vCenter Server, how to quickly deploy the vCSA and how to configure an external Oracle database for larger deployments.

For more information about the vCSA, please see the resources listed here https://vmwire.com/vmware-vcenter-server-virtual-appliance-vcsa/.

The location of the sysprep directory on the vCSA is located in

/etc/vmware/vmware-vpx/sysprep/

To get to this location, use a SSH client like WinSCP or FileZilla. The vCSA comes pre-configured with sshd, so no further action needs to be taken here.

Login as root | vmware

You’ll see the following folder structure within the /etc/vmware-vpx/sysprep/ directory:

1.1

2k

svr2003

svr2003-64

xp

xp-64

Note that Vista, Windows 2008 and Windows 7 are not listed, this is because sysprep is built into those operating systems and vCenter can already leverage this. Guest Operating System Customizations with the vCSA is also supported with Linux operating systems out of the box (no configuration to the vCSA is required), although sysprep is obviously not required, please see the Guest OS Customization Support Matrix for supported Linux distributions.

Follow the vSphere Virtual Machine Administration Guide for instructions on extracting the necessary sysprep files, these files can be found in the DEPLOY.CAB file. If you’re migrating from the Windows vCenter Server to the vCSA, just copy the above directories over.

To obtain the sysprep files, you can use the installation CD/DVDs for each operating system or use the following links to download them (these links are detailed in VMware KB1005593):

Windows Version vCSA Sysprep Directory Sysprep Version
Windows 2000 Server SP4 with Update Rollup 1

http://www.microsoft.com/downloads/details.aspx?FamilyID=0c4bfb06-2824-4d2b-abc1-0e2223133afb

Or

The updated Deployment Tools are available in the Support\Tools\Deploy.cab file on the Windows 2000 SP4 CD-ROM. To download this file, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/windowsserver/2000/bb735341.aspx

 /etc/vmware-vpx/sysprep/2k 5.0.2195.2104
Windows XP Pro SP2

http://www.microsoft.com/downloads/details.aspx?FamilyId=3E90DC91-AC56-4665-949B-BEDA3080E0F6

 /etc/vmware-vpx/sysprep/xp 5.1.2600.2180
Windows 2003 Server SP1

http://www.microsoft.com/downloads/details.aspx?familyid=A34EDCF2-EBFD-4F99-BBC4-E93154C332D6

 /etc/vmware-vpx/sysprep/svr2003

5.2.3790.1830

(srv03_sp1_rtm.050324-1447)
Windows 2003 Server SP2

http://www.microsoft.com/downloads/details.aspx?FamilyID=93f20bb1-97aa-4356-8b43-9584b7e72556

 /etc/vmware-vpx/sysprep/svr2003

5.2.3790.3959

(srv03_sp2_rtm.070216-1710)
Windows 2003 Server R2

http://www.microsoft.com/downloads/details.aspx?FamilyID=93f20bb1-97aa-4356-8b43-9584b7e72556&displaylang=en

 /etc/vmware-vpx/sysprep/svr2003

5.2.3790.3959

(srv03_sp2_rtm.070216-1710)
Windows 2003 x64http://www.microsoft.com/downloads/details.aspx?familyid=C2684C95-6864-4091-BC9A-52AEC5491AF7&displaylang=en /etc/vmware-vpx/sysprep/svr2003-64

5.2.3790.3959

(srv03_sp2_rtm.070216-1710)
Windows XP x64http://www.microsoft.com/downloads/details.aspx?familyid=C2684C95-6864-4091-BC9A-52AEC5491AF7&displaylang=en /etc/vmware-vpx/sysprep/xp-64

5.2.3790.3959

(srv03_sp2_rtm.070216-1710)
Windows XP Pro SP3

http://www.microsoft.com/downloads/details.aspx?familyid=673a1019-8e3e-4be0-ac31-70dd21b5afa7&displaylang=en

 /etc/vmware-vpx/sysprep/xp 5.1.2600.5512

Guest Operating System Customization Requirements

Guest operating system customization is supported only if a number of requirements are met.

VMware Tools Requirements

The most current version of VMware Tools must be installed on the virtual machine or template to customize the guest operating system during cloning or deployment.

Virtual Disk Requirements

The guest operating system being customized must be installed on a disk attached as SCSI node 0:0 in the virtual machine configuration.

Windows Requirements

Customization of Windows guest operating systems requires the following conditions:

  • Microsoft Sysprep tools must be installed on the vCenter Server system.
  • The ESXi host that the virtual machine is running on must be 3.5 or later.

Linux Requirements

Customization of Linux guest operating systems requires that Perl is installed in the Linux guest operating system.

Guest operating system customization is supported on multiple Linux distributions.

Verifying Customization Support for a Guest Operating System

To verify customization support for Windows operating systems or Linux distributions, see the Guest OS Customization Support Matrix.

A look at VMware vCloud Director Organization LDAP Authentication Options

VMware vCloud Director can use three different authentication mechanisms for subscriber authentication to the VCD portal. The portal is accessed using the URL https://<cloud-url>/cloud/org/<organisation>. In this post, I’ll try to highlight some of the authentication options that a subscriber can use to access the VCD portal.

Supported LDAP Services

Platform LDAP Server Authentication Methods
Windows Server 2003 Active Directory Simple, Simple SSL, Kerberos, Kerberos SSL
Windows Server 2008 Active Directory Simple
Windows 7 (2008 R2) Active Directory Simple, Simple SSL, Kerberos, Kerberos SSL
Linux OpenLDAP Simple, Simple SSL

VCD LDAP Options

A provider can configure a subscriber to use three different authentication mechanisms as highlighted by Figure 1.

Figure 1 – VCD LDAP Options

  1. Do not use LDAP (also known as local authentication)

    This is the simplest authentication method, selecting this radio button when configuring a new Organization will not use any kind of LDAP service. Instead, new users will need to be configured using the VCD GUI or the VCD API, and these users will be stored within the VCD database. Some of the disadvantages when using the local authentication are:

  • Groups cannot be used
  • A minimum length of 6 character only
  • No password complexity policies
  • No password expiration policies
  • No password history
  • No authentication failure controls
  • No integration with enterprise identity management systems
  1. VCD system LDAP service

    Selecting this will force the Organization to use the same LDAP service as the LDAP service that is used by the VCD system (Provider). Although, a separate OU can be used for each Organization, this is not the ideal model to use for large cloud deployments. Some of the disadvantages when using the VCD system LDAP service are:

  • Organizations must use the same LDAP service as the Provider.
  • Although separate OUs can be used, Organizations may not want to have their Users and Groups managed by the Provider.
  • Organizations may not want to share the same LDAP service with another Organization, even if separate OUs are used.
  • No self-service of the LDAP service by each subscriber is possible unless complex access is setup for each subscriber to their respective OU.
  1. Custom LDAP service

    Selecting this will allow the Organization to use its own private LDAP service. What this means is for each Organization, a completely separate and unique LDAP service can be used for that Organization, an Organization does not need to use the same service as the VCD system but can use its own LDAP service. This can be a completely separate unique Active Directory Forest for example, with no network links to any other AD Forest.

VCD System LDAP Service

Consider this following example:

I run a Public Cloud so I am a Provider of cloud services, my VCD system authenticates to a Microsoft Active Directory Forest with a domain name of HUGO.LOCAL. This allows me as a System Administrator to log into my VCD portal as a user on HUGO.LOCAL.

As the System Administrator, I first configure an LDAP service for the VCD System:

Figure 2 – VCD System LDAP

Then, a new Security Group called SG_VCD.System.Administrators is created in the HUGO.LOCAL domain, with the user HUGO.LOCAL\HPhan as a member of that group.

Figure 3 – VCD System Administrators Group

The new Security Group SG_VCD.System.Administrators is then added to the System Administrator role in VCD.

Figure 4 – Import LDAP group into VCD role

Now I can log into my cloud as a System Administrator with my domain user HUGO\HPhan.

Figure 5 – System LDAP

Organization Custom LDAP Service

So pretty easy and straightforward so far right? What happens when a subscriber comes along and wants to use my cloud services? Let’s do another example.

A new organization let’s say Coke, wish to use their own LDAP service to authenticate with the VCD portal. In much the same way as how the System LDAP was configured, an Organization LDAP service is configured in similar ways.

As a System Administrator, I first configure a LDAP service for the Coke Organization, instead of using the HUGO.LOCAL LDAP service, I now direct this Organization’s LDAP service to a unique LDAP service for Coke. This can be a LDAP service hosted by me (the Provider) and managed by Coke (think co-lo), or a LDAP service managed by Coke in Coke’s datacentres (think MPLS/IPVPN):

Figure 6 – Organization LDAP

Then a new Security Group called Organization Administrators is created in the COKE.LOCAL domain, with the user COKE.LOCAL\John.Smith as a member of that group.

Figure 7 – VCD Organization Administrators Group and Members


The new Security Group Organization Administrator is then added to the Organization Administrator role in Coke’s Organization.

Figure 8 – Assign LDAP Group to VCD Role

John Smith can log into the Coke Organization as an Organization Administrator with the domain user COKE\John.Smith.

Figure 9 – LDAP User logged into VCD

So what happens when another Organization joins the party? Extending our example above, let’s say Pepsi also want to use my cloud services. In much the same way that the Coke Organization is configured to use its own LDAP service, we do the same for the Pepsi Organization – an Organization Administrator group is created in the PEPSI.LOCAL domain, and a user named Peter.Smith is a member of that group, Peter Smith can also log into Pepsi’s Organization as an Organization Administrator.

Figure 10 – Another LDAP User logged into VCD

In Summary

In summary the provider will use the System LDAP, all other (subscribers) Organizations could also use the System LDAP (either with a separate OU or not) if required, however, you can also configure each Organization to use its own LDAP Service.

  • We have a Provider which uses the domain HUGO.LOCAL to authenticate the System VCD, with the Active Directory Security Group SG_VCD.System.Administrators having the System Administrator role in VCD and my account HUGO\HPhan is a member of this group.
  • We have subscriber 1 with an Organization named Coke Co, and this organization uses its own LDAP service which is backed by a domain COKE.LOCAL.
  • We have another subscriber, subscriber 2 with an Organization named Pepsi Co, and this organization uses its own LDAP service which is backed by a domain PEPSI.LOCAL.
  • Provider – Uses HUGO.LOCAL – System LDAP
  • Subscriber 1 – Uses COKE.LOCAL – Custom LDAP
  • Subscriber 2 – Uses PEPSI.LOCAL – Custom LDAP
  • There is no trust between the Provider LDAP or any Subscribers’ LDAP required.
  • More importantly, there is no trust and no network connectivity between any of the subscriber’s LDAP systems.

Securing Custom LDAP Services

For each Organization, a single LDAP Service for that Organization will need to be configured as a Custom LDAP to authenticate to. To enable this functionality, the vCloud Director Cell must be able to connect to ALL LDAP servers over TCP 389 or 636. The VMware vCloud Security Hardening Guide gives good recommendations on how Service Providers can host Subscribers’ LDAP servers and also how to maintain connectivity to Subscribers’ LDAP servers if hosted remotely over MPLS/VPN etc.

It is therefore important that the vCD Cell is secured and network connectivity to each organization’s LDAP services are also secured. The following extract from the VMware vCloud Security Hardening Guide explains the connectivity options for subscriber’s LDAP services:

Connectivity from the VMware vCloud Director cells to the system LDAP server and any Organization LDAP servers must be enabled for the software to properly authenticate users. As recommended in this document, the system LDAP server must be located on the private management network, separated from the DMZ by a firewall. Some cloud providers and most IT organizations will run any Organization LDAP servers required, and those too would be on a private network, not the DMZ. Another option for an Organization LDAP server is to have it hosted and managed outside of the cloud provider’s environment and under the control of the Organization. In that case, it must be exposed to the VMware vCloud Director cells, potentially through the enterprise datacenter’s own DMZ (see Shared Resource Cloud Service Provider Deployment above).

In all of these circumstances, opening the appropriate ports through the various firewalls in the path between the cells and the LDAP server is required. By default, this port is 389/TCP for LDAP and 636/TCP for LDAPS; however, this port is customizable with most servers and in the LDAP settings in the Web UI. Also, a concern that arises when the Organization is hosting their own LDAP server is exposing it through their DMZ. It is not a service that needs to be accessible to the general public, so steps should be taken to limit access only to the VMware vCloud Director cells. One simple way to do that is to configure the LDAP server and/or the external firewall to only allow access from IP addresses that belong to the VMware vCloud Director cells as reported by the cloud provider. Other options include systems such as per-Organization site-to-site VPNs connecting those two sets of systems, hardened LDAP proxies or virtual directories, or other options, all outside the scope of this document.

Figure 11 – Multiple Custom LDAP in VCD

Note: The use of Coke and Pepsi are used as an example of multi tenancy within a public cloud and the use of the names on this blog are for information purposes only.

Configuring vCenter Server Virtual Appliance to use an Oracle database

In previous posts I blogged about what the vCenter Server Virtual Appliance (vCSA) is, its features and benefits, feature parity with the Windows vCenter Server and also how to quickly deploy the vCSA. For more information about the vCSA, please see the resources listed here https://vmwire.com/vmware-vcenter-server-virtual-appliance-vcsa/.

This post extends the series with how to configure an external Oracle database for use by the vCSA.

Why use an Oracle database?

The vCSA comes preinstalled with an embedded DB2 database which has similar use cases as the Windows vCenter Server when configured with SQL Express – intended for small deployments of 5 ESX/ESXi servers or less. The ability for the vCSA to utilise an external Oracle database allows customers to scale and manage larger vSphere infrastructures equivalent to environments with Windows vCenter Servers backed by SQL or Oracle databases.

This post shows how quickly and easily it is to use an external Oracle database instead of the embedded DB2 database. Hopefully you’ll see the benefits of how much quicker it is to configure the Oracle connectivity between the vCSA and the Oracle server vs installing the Oracle 64-bit Client onto a Window Server and configuring tnsnames.ora, followed by configuration of ODBC settings.

Configure an Oracle Database and User

  1. Log into SQL*Plus session with the system account. I’m using Oracle 11g R2 x64 on Windows Server 2008.
    C:`>sqlplus sys/<password> as SYSDBA
  2. Run the following SQL commands to create a vCenter Server database. Note that your directory structure may be different.

    CREATE SMALLFILE TABLESPACE “VPX” DATAFILE ‘e:/app/oracle/oradata/orcl/vpx01.dbf’ SIZE 1G AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

  3. Run the following SQL command to create a vCenter Server database user with the correct permissions. I will create a new user named “VPXADMIN” with a password of “oracle”.
    CREATE USER "VPXADMIN" PROFILE "DEFAULT" IDENTIFIED BY "oracle" DEFAULT TABLESPACE "VPX" ACCOUNT UNLOCK;
grant connect to VPXADMIN;
grant resource to VPXADMIN;
grant create view to VPXADMIN;
grant create sequence to VPXADMIN; 
grant create table to VPXADMIN; 
grant create materialized view to VPXADMIN;
grant execute on dbms_lock to VPXADMIN;
grant execute on dbms_job to VPXADMIN;
grant select on dba_tablespaces to VPXADMIN;
grant select on dba_temp_files to VPXADMIN;
grant select on dba_data_files to VPXADMIN;
grant unlimited tablespace to VPXADMIN;

Configure the vCSA

  1. Log into the vCSA VMware Studio management interface at https://<vcsa>:5480/
  2. Navigate to the vCenter Server tab, then click on Database.
  3. Select oracle as the Database Type using the drop-down menu and enter your environment information into the fields and then click on Save Settings. Note how easy that was, no messing about with installing the Oracle Client, no need to configure tnsnames.ora and no need for any ODBC configuration either.

  4. Wait for around 5 minutes for the vCSA to create the database schema.
  5. Now it’s safe to start the vCenter services, navigate to the Status tab and click on Start vCenter.

  6. You can then start using vCenter when the Service Status reports as Running.

Cleaning up the Oracle configuration

After you’ve tested that everything is working, you can revoke the following privileges using SQL*Plus again.

revoke select on dba_tablespaces from VPXADMIN;
revoke select on dba_temp_files from VPXADMIN;
revoke select on dba_data_files from VPXADMIN;

Total configuration time ~approx 10 minutes.

References

vSphere Installation and Setup Guide

My VCDX Journey – 5 simple steps to VCDX

I’ve just recently been awarded the VCDX4 certification after completing my defence in Frankfurt. It is part of the final stage in the VCDX certification culminating in a journey over the past year. Defence experiences have been shared by others such as Duncan Epping, Jason Boche, Scott Lowe and Kenneth van Ditmarsch and I found that mine was very similar so this is a post on how I prepared for my VCDX and by careful planning how it can be achieved within 12 months.

For information regarding the VCDX certification path, please see the VCDX page on VMware.com.

First a quick thanks to all those that helped in true Oscar style, namely Steve Byrne my manager at VMware for supporting my journey, my colleagues at VMware for your help with the mock panels, you were awesome – @simonlong_, @repping, @ady189, @baecke & John Pollard. A shout out to @frankdenneman for the motivational support and advice.

Fail to plan? Then plan to fail, preparation is key, so this was how I planned my journey in 5 easy steps.

Step 1 – Gain support from your employer and family

This is critical as the certification path is not an easy one, there is a minimum of one course to attend (vSphere ICM), three exams (VCP, VCAP-DCA, VCAP-DCD) and fees for the VCDX submission and defence. Not to mention the expenses of travelling to the defences themselves. It’s also good to agree time to study, work on your defence materials as well as any time you need to actually attend the defence. Remember that taking time out to study and prepare would mean your company would take the hit on your productivity. So having a mutual agreement benefits all.

Support from your family is also a must as it will be a huge investment in your time.

Step 2 – Set clear objectives

Sit down with your manager and discuss clear objectives that are SMART. Agree on what your objectives are, and plan to achieve them. An example:

Objective Estimated Completion Date Resources
VCP Q1 ICM course, lab practice
VCAP-DCA Q2 Courses (optional), lab practice
VCAP-DCD Q3 Design Workshop (optional), read PDFs, lab practice
Create a vSphere Design Q2-Q3 Work on real design for a customer with real world requirements and use this as your VCDX submission
Complete VCDX Submission Q4 Choose a VCDX defence date and aim to submit your VCDX materials in time

Step 3 – Keep a track of your progress

Remember to keep a track of your progress, if you pass the exams, share the news with your team, it keeps you motivated. If you fail, then your timeline objectives may need tweaking. Keep your manager in the loop with progress, as ultimately, funding needs to come from somewhere for your fees and expenses right?

Step 4 – Work on your VCDX materials and then submit

Read the VCDX requirements and register your intention to pursue the VCDX on myLearn and make sure that you meet all the requirements before sending in your submission. Make sure to get some colleagues to review your documents first.

If everything goes well, your submission may well be accepted by VMware and you’re invited to defend.

Step 5 – Prepare for your defence

At this stage you should have been invited to defend. This is the most critical stage of the process, all the work that you’ve done so far has ultimately come down to this. So no pressure.

There are many ways to prepare, but here’s how I made myself ready for the defence.

1. Request peer reviews from your colleagues and virtualisation friends. Ask them to review all of your documents and materials again, especially the design.

2. Run Webex sessions with your peers to go over your 15 minute VCDX presentation. Record this, it will help you review your performance, note the duration and your tone of voice, did you project well?

3. Conduct a mock defence session with your peers. Invite them to ask as many questions that they could think of, even the obvious ones. Record this as well, note your performance, how you responded to the questions, tone of voice, setup a BS counter. Too much BS means that you don’t know your design well enough and you’ll be at risk when it comes to your real defence. Just remember to be – clear – concise – calculated.

4. Practice white boarding, you will have at least one whiteboard at your defence and it’s your most powerful tool, so learn to use it like it’s second nature.

5. Know your design inside out, not just the technical aspects. If you can justify the technical design decisions back to the business and technical requirements and constraints then you’re on the right track.

6. If you feel that you’re not ready or you can’t make it to your defence, you can postpone it to the next defence dates without submitting your application again. I was initially scheduled to defend in Singapore but could not travel so defended in Frankfurt instead.

Well that’s my advice, I hope this information is useful and that it helps more people being able to attain the VCDX certification. Who knows I might see you on the other side of the table in 12 month’s time. 😀

Creating vSphere 5 ESXi embedded USB Stick

A very quick post on how to create an image that contains vSphere 5 ESXi Embedded with which you can use to quickly create USB sticks that have the ESXi hypervisor installed.  This is not the same as creating a bootable USB key that contains the installation files to install ESXi from the USB stick.  For this method please refer to this post.

Use this in your lab environment, I wouldn’t recommend doing this in production environments.

In previous versions of vSphere ESXi, it was relatively straight forward to create a bootable USB key which already contained the ESXi hypervizor.  This was done by extracting the files from the ISO and then using ‘dd’ to image the directory structure to the USB stick.  With vSphere ESXi 5 however, this technique is no longer possible.  There is a workaround however.  ESXi is installed and configured in two steps, the installation is done to a disk with a vanilla installation of ESXi without configuration.  The server is then rebooted and the configuration of ESXi continues with the creation of the management network vmk0 or vmk1 (depending on your setup), hostname, DNS etc.

For this to work, we do not perform the second part, which is the configuration, but take an image of the USB key directly after the installation of the vanilla installation of ESXi without configuration.  This enables us to image this vanilla installation onto as many USB sticks, i.e., servers as we like without clashes in virtual MAC addresses and the like.

What you will need: VMware Workstation, 1 USB stick, the ESXi Installable ISO file VMware-VMvisor-Installer-5.0.0-469512.x86_64.iso, WinImage.

Quick steps

  1. Create a new ESX virtual machine in VMware Workstation with CD-ROM drive, USB adapter, 2Gb RAM and 2vCPUs.
  2. Mount the ESXi Installable ISO file to the CD Drive.
  3. Insert the USB stick to your workstation (the same one that runs VMware Workstation).
  4. Boot the VM and connect the USB stick to the VM.
  5. Install ESXi as normal, making sure that you install onto the USB stick, when installation is complete, disconnect the USB stick from the VM and do not reboot the VM, just turn it off.  You no longer need this VM.
  6. With the USB stick still connected to your workstation, open up Winimage.
  7. Go to Disk | Creating Virtual Hard Disk image from physical drive and select the USB stick that you installed ESXi on.
  8. Select a location where to save your image and change the file type to Image file (*.ima).
  9. WinImage will now make a backup on your newly installed USB stick.

Creating vSphere 5 ESXi embedded bootable USB sticks

  1. Now that you have an ESXi image, you can use this to build lots of USB sticks which are ready for ESXi deployment.
  2. Insert a new USB stick into a spare USB port.
  3. Launch WinImage and navigate to Disk | Restore Virtual Hard Disk image on physical drive.
  4. Select the USB stick and click on OK.
  5. Navigate to the image file that you created previously.  WinImage will now restore the backed up image to your new USB stick.
  6. Repeat as necessary.

Configure ESXi

Once the stick is ready, just insert into a spare USB port on your server and ESXi will boot into the configuration screen ready for you to configure management network details.

You may need to log onto the local console once ESXi has finished booting and launch the ‘Restore Network Settings’.  This will reset the vmk0 or vmk1 (depending on your setup) interface.

VMware vCenter Server Virtual Appliance (vCSA) Feature Parity

In a previous article I wrote about the vCSA’s features and benefits.  This post lists the interoperability or feature parity of the vCSA and the Windows vCenter Server.  For more information about the vCSA, please see the resources listed here https://vmwire.com/vmware-vcenter-server-virtual-appliance-vcsa/.

A few readers have asked what works with the vCSA and what does not.

The vCSA supports all vCenter features – DRS, SDRS, HA, Host Profiles, dvSwitches, etc.

Secondary architecture features like supported DB, View Composer are not yet at feature parity with the Windows vCenter Server.

Not supported yet:

  • Microsoft SQL as the database for vCenter – requires stable ODBC driver for Linux that can scale.
  • vCenter Server Linked Mode – requires ADAM.
  • vCenter Server Heartbeat – requires Windows.
  • IPv6.
  • Single sign-on using Windows session credentials.
  • VMware View Composer (Linked Clones) – installed on Windows vCenter Server only.
  • vSphere Storage Appliance – VSA Manager & VSA Cluster Server installed on Windows vCenter Server.
  • VIX Plugin for vCenter Orchestrator – VMware Tools API only works with Windows vCenter Server.

Other VMware products that work with the vCSA:

  • vCenter Operations.
  • vCenter Orchestrator.
  • vCenter CapacityIQ.
  • SRM5.
  • VMware View 5 (no Linked Clones).
  • Auto Deploy.
  • vCenter Update Manager.
  • vMA.
  • vSphere Client.
  • vSphere Web Client.
  • VMware vCloud Director.
  • PowerCLI.
  • vSphere Client for iPad & vCMA.

If I find anything else, I’ll update the article.

VMware vCenter Server Virtual Appliance (vCSA) features and benefits

The VMware vCenter Server Virtual Appliance (vCSA) provides an alternative option for organizations that chose not to run the Windows vCenter Server but still require centralised management of VMware vSphere deployments in the enterprise.

It provides exactly the same functionality as the traditional Windows vCenter Server but packaged in a Linux distribution. I know that some of my pure UNIX and LINUX customers have been asking for this for a while.

It’s been available as a technology preview since 2009 as “vCenter 2.5 on Linux” but has finally arrived with vSphere 5 to give customers’ an alternative to the Windows vCenter Server. Expect to see it available for download when vSphere 5 goes GA.

*UPDATE* vSphere5 is now GA, and the vCSA is available to download here.

For more information about the vCSA, please see the resources listed here https://vmwire.com/vmware-vcenter-server-virtual-appliance-vcsa/.

I’ve been using it for a while now in the lab and have found it very easy to deploy and use. vCenter services start a lot quicker and the user experience with the VMware vSphere Client is exactly the same.

vCenter Server Virtual Appliance features and benefits

  • Installed on SUSE Linux Enterprise Server 11 x64.
  • OVF when deployed is configured with 2vCPUs and 8Gb memory, LSI Logic Parallel, VMXNET 3, 15Gb and 60Gb VMDKs and VMware Tools.
  • Includes embedded DB2 database that is suitable for evaluation or for environments with less than 5 ESXi hosts or 50 virtual machines (equivalent to Windows vCenter Server + MSSQL Express).
  • Supports external Oracle database for large environments.
  • Includes Active Directory (AD) and Network Information Services (NIS) authentication.
  • vSphere Web Client support is built into the vCenter Server Virtual Appliance. vSphere Web Client is OS agnostic and the interface is highly customisable.
  • Windows vSphere Client is still supported.
  • Includes a pre-configured Auto Deploy server therefore reducing operational costs with the installation of Auto Deploy.
  • Can use NFS mounts to store vCenter Server Virtual Appliance core and log files.
  • vCSA can act as a syslog server for ESXi system logs.
  • Can be used as a network collector for ESXi kernel core dumps.
  • Simplified and rapid deployment, approximately 15 minutes deployment time.
  • Lower TCO by eliminating Windows OS dependency and licenses.
  • Reduces operational costs – vCSA is easier to upgrade – just deploy a new appliance and connect to the external Oracle database or
  • Import configuration data from previous installation.
  • Patches can be installed using the vCSA web interface.

Not yet feature parity with Windows vCenter Server

vCenter Server Virtual Appliance provides all features as the Windows vCenter Server but does not support the following features:

  • Microsoft SQL as the database for vCenter.
  • vCenter Server Linked Mode.
  • vCenter Server Heartbeat.
  • IPv6.

For details on what products are supported with the vCSA please see this post.

I’ve provided a quick start guide including a 10-minute how-to video demonstrating the deployment and administration in this post.

vSphere 5 vCenter Server Virtual Appliance Quick-Start Guide

The vCenter Server Linux Virtual Appliance (vCSA) is a preconfigured Linux-based virtual machine that is optimized for running vCenter Server and associated services.

This article provides a step-by-step guide on how to deploy the vCSA, configure networking, authentication, database and vCenter services.  For further information regarding the vCSA please refer to this post and this post.  To use an external Oracle database instead of the embedded DB2 database, please see this post.

For more information about the vCSA, please see the resources listed here https://vmwire.com/vmware-vcenter-server-virtual-appliance-vcsa/.

Note: This article was written using the release candidate version of the software so your experience with the GA version may differ slightly.

The following table lists the required files that you will need, gather these files before proceeding.

Description Filename Location Size (KB)
vCenter Appliance .cert file VMware-vCenter-Server-Appliance-5.0.0.2968-380565_OVF10.cert 2
vCenter Appliance .mf file VMware-vCenter-Server-Appliance-5.0.0.2968-380565_OVF10.mf 1
vCenter Appliance .ovf file that is used to import the appliance onto a vSphere server VMware-vCenter-Server-Appliance-5.0.0.2968-380565_OVF10.ovf 9
vCenter Appliance data disk VMware-vCenter-Server-Appliance-5.0.0.2968-380565-data 43,365
vCenter Appliance system disk VMware-vCenter-Server-Appliance-5.0.0.2968-380565-system 4,029,063
vSphere 5 Client VMware-viclient-en-5.0.0-380461 310,475

Watch the 10-minute video (Optimised for iPad)

Deploy the vCenter Server Linux Virtual Appliance

  1. Launch your vSphere Client and navigate to File | Deploy OVF Template.
  2. Browse to the location of the vCenter Appliance .ovf file, then click on Open.
  3. On the following screen click on Next.
  4. Then click on Next again on the OVF Template Details page.
  5. Under Name and Location, give your vCenter Appliance a name then click Next.
  6. Choose a datastore then click Next.
  7. Select a disk format on the next page then click on Next to continue.
  8. Click on Finish to start deploying.

Configuring the vCenter Server Linux Virtual Appliance

  1. Boot the appliance.
  2. Open a vSphere Client console session to the virtual appliance and configure the network and timezone.
  3. Now open up a browser and type https://<ip_of_appliance&gt;:5480 to continue the configuration.
  4. Accept the certificate error to continue.
  5. Login as root, the default password is vmware.

  1. Now read through every single word of the EULA and click on Accept EULA to continue. Please be patient whilst the vCenter is configured. If you look at the appliance remote console you’ll see the services being configured and started.

  1. You can start using the web interface again once the console screen returns to default.

  1. Next click on Status, and view the current status of the vCenter Server. The service should be on a Stopped state and the Database Type should show not configured.
  2. Click on the tab, you will notice that there are no DNS Servers configured and the appliance’s hostname is the standard localhost.localdom, lets change this.
  3. Click on and change to your relevant values and click on to complete the network configuration.
  4. Now setup authentication by clicking on and then on either NIS or Active Directory. My lab environment uses AD.
  5. Click on the tick box and then fill in your domain details and then click on Save Settings. You should receive an Operation is successful message to confirm that the authentication settings has worked.
  6. We now need to configure a database for vCenter to use, for this article, let’s use the embedded DB2 database. Click on to continue.
  7. When using the embedded database, there is no need to enter any details, just click on . This will take a while to complete, once done click on . After some time the database will complete configuration.
  8. Now reboot the virtual appliance one last time. To reboot click on and then click on . Click Reboot again to confirm.
  9. This time the vCenter Appliance will successfully start the vpxd daemon and initialize the database, eventually vCenter 5.0 will be ready for you to use.

Connecting to vCenter 5.0 for the first time

With all VMware vSphere Clients, when you start the vSphere Client and connect to either a vCenter Server or an ESX/ESXi host, it will check whether the vSphere Client is compatible. This is still the case with vSphere 5.0 and you will need to update your vSphere Client if you haven’t already done so. You can update by connecting to vCenter Server or ESX/ESXi or you can download the vSphere Client executable from the VMware Downloads website.

  1. Launch the vSphere Client and connect to your newly configured vCenter Server.
  2. You must use root | vmware to login, domain credentials will not work until the permissions are added to vCenter.

  1. Update the vSphere Client as necessary.
  2. Add an AD group into vCenter permissions and set the role as Administrator. [See video].
  3. Now you will be able to log in with domain credentials.
  4. You will need to enter your username in DOMAIN\Username or username@DOMAIN format.

It is also possible to just use the vSphere Web Client by opening up a browser session to https://&lt;ip_of_vCSA>:9443/vsphere-client/

A List of VMware Employee Tweeps (people on Twitter)

Following on from the PSO NEMEA twitter list, I decided to go further and produce this list of VMware employees that are on Twitter, sorted alphabetically by Twitter ID as of 29/06/2011.

Let me know if I have missed you out or you follow someone that works for VMware.

Twitter ID Name Blog
Adrian Roberts  
Alan Renouf www.virtu-al.net
Andrew Mitchell  
Andy Banta  
Arnim van Lieshout www.van-lieshout.com
Kamau Wanguhu www.borgcube.com
Brian Thomas Rice  
Chris Colotti www.chriscolotti.us
Christophe Decanini www.vcoteam.info
Christoph Harding www.thatsmyview.net
Brittany Coulson  
Carter Shanklin  
Dale Carter www.delboycarter.com
Dave Hill www.virtual-blog.com
Douglas Phillips  
Richard Damoser  
Duncan Epping www.yellow-bricks.com
Eric Gray www.vcritical.com
Frank Denneman www.frankdenneman.nl
Frank Wegner  
Hany Michael www.hypervizor.com
Andy Troup  
Stephen Herrod www.vmware.com/company/leadership.html
Pablo Roesch  
Hugo Strydom www.vroem.co.za
Hugo Phan www.vmwire.com
Jean-Francois Richard  
Jerry Chen  
Johnny Krogsboll  
Joe Sarabia  
John Troyer  
Julie Escott  
Greg A Lato www.latogalabs.com
Lode Vermeiren lodev.name
Max Daneri  
Manish Patel  
Mark Verhagen  
Martyn Storey  
Matthew Meyer  
Dave McCrory blog.mccrory.me
Matt Coppinger
Michael Haines  
Mike DiPetrillo www.mikedipetrillo.com
Massimo Re Ferre’ it20.info
Nadyne Richmond www.nadynerichmond.com
Peter Giordano petergiordano.com
Paul Nothard  
Rawlinson Rivera www.punchingclouds.com
Rasmus Jensen www.vpeeling.com
Ray Heffer www.rayheffer.com
Raymon Epping  
Richard McDougall blog.richardmcdougall.com
Rick Blythe www.vmwarewolf.com
Robin Prudholm  
Rob Upham  
Safouh Kharrat  
Scott Davis blogs.vmware.com/view-point
Simon Long www.simonlong.co.uk
Steve Jin www.doublecloud.org
Scott Sauer unhub.com/ssauer
Stan Hutten Czapski  
Susan Gudenkauf  
Burke Azbill www.vcoteam.info
Tedd Fox about.me/teddfox
Richard Garsthagen www.run-virtual.com
John Dodge www.dodgeretort.com
Tom Ralph about.me/TomRalph
Tony Dunn  
Tristan Todd  
Timo Sugliani  
Jason Miles  
John Arrasjid  
Alexander Thoma  
Vegard Sagbakken   
Vic Camacho wefollow.com/Virtual_Vic
Andrew Johnson  
Irfan virtualscoop.org
Todd Muirhead  
Mark C  
Josh Liebster vmsupergenius.com
Vittorio Viarengo journeytocloud.com
Wade Holmes  
Willem van Engeland  
Jian Zhen zhen.org

VMware PSO NEMEA Twitter List

A list of VMware PSO consultants covering NEMEA that are on Twitter, sorted alphabetically by Twitter ID.

Follow us for tweets from the real world.

Map created using templates from http://www.presentationmagazine.com.

How to update your Openfiler USB installation for better performance

Previously I wrote an article on How to install and run Openfiler on a USB key. I thought that everything was working fine but eventually found that NFS and CIFS performance was too slow. Upon reading a few forums and stumbling across this thread in particular, the reason was down to Openfiler requiring an update.

I have since tried to update the installation by running conary updateall at the CLI. Unfortunately, this installs an updated kernel (2.6.29.6-0.24.smp.gcc3.4.x86_64 (SMP)) and also a new ramdisk which makes all the hard work from the previous post defunct. This article shows you how to perform the update and then make a new initrd-usb-update.img to work with the new kernel.

So assuming you’ve made a successful USB key using the previous article, continue with the following to update your Openfiler installation and also make the updated Openfiler installation USB key bootable.

Update Openfiler

Let’s first update Openfiler.

  1. Log into the CLI as root
  2. Run

    conary updateall

  3. This will take a while as it downloads around 26 packages and installs them.
  4. Once complete insert the Openfiler CD into your drive and restart your system, making sure that it boots from CD.

Creating a new ramdisk that works with the new kernel

This part is more or less very much similar to the steps in the previous post, there are some minor additions that we need to make, but for completeness I’ve included all the steps here.

  1. Once Openfiler finishes booting from the CD type.

    linux rescue

  2. Go through the menus and select your region and keyboard and skip the automatic mounting of your installed OS. We will do this manually.
  3. When the prompt appears, create a directory to mount the USB key.

    mkdir /mnt/sysimage

  4. Now mount the / of the USB key onto /mnt/sysimage.

    mount /dev/sda2 /mnt/sysimage

    Note: your / partition may be /dev/sda3 instead, depending on how you setup your partitioning during the installation of Openfiler.

  5. Now mount the boot partition of the USB key onto /mnt/sysimage/boot.

    mount /dev/sda1 /mnt/sysimage

    Note: your / partition may be /dev/sda1 instead, depending on how you setup your partitioning during the installation of Openfiler.

  6. Make the /mnt/sysimage your working environment by changing your root location so you are working on the file system on the usb key.

    chroot /mnt/sysimage

  7. Copy the current initrd file to a temporary location where we can work on it.

    cp /boot/initrd-1 /tmp/initrd.gz

    Note1: now’s a good time to press TAB, there will now be two kernels, use 2.6.29.6-0.24.smp.gcc3.4.x86_64 as this is the updated kernel that was installed during the update.

  8. Gunzip the initrd.gz file

    gunzip /tmp/initrd.gz

  9. Make a temporary working directory

    mkdir /tmp/b

    We are using /tmp/b because /tmp/a already exists as the temporary working directory from the previous article.

  10. Go into the new working directory

    cd /tmp/b

  11. Extract the contents of the initrd file into /tmp/b.

    cpio –i < /tmp/initrd

  12. Now we edit the init file to load the USB and SCSI drivers for the new initrd-usb-update.img ramdisk.

    nano init

  13. Do a search for “mount –t proc /proc /proc” and add the following underneath this line. We want to load these USB and storage modules before any other modules that’s why these entries need to be at the top of the file. Note that there is a new module crc-t10dif.ko which is required by the new kernel to boot from USB and as such must be launch during init time.

    echo “Starting Openfiler on USB”

    echo “Loading scsi_mod.ko module”

    insmod /lib/scsi_mod.ko

    echo “Starting crc-t10dif.ko module”

    insmod /lib/crc-t10dif.ko

    echo “Loading sd_mod.ko module”

    insmod /lib/sd_mod.ko

    echo “Loading sr_mod.ko module”

    insmod /lib/sr_mod.ko

    echo “Loading ehci-hcd.ko module”

    insmod /lib/ehci-hcd.ko

    echo “Loading uhci-hcd.ko module”

    insmod /lib/uhci-hcd.ko

    echo “Loading ohci-hcd.ko module”

    insmod /lib/ohci-hcd.ko

    sleep 5

    echo “Loading usb-storage.ko module”

    insmod /lib/usb-storage.ko

    sleep 5

  14. Do a search for insmod /lib/scsi_mod.ko, insmod /lib/sd_mod.ko, insmod /lib/ehci-hcd.ko, insmod /lib/uhci-hcd.ko and /lib/crc-t10dif.ko and remove these duplicate entries from the rest of the file. We do not want these loaded again.
  15. Save the file and exit with CTRL X, then Y, or if you used vi then :wq!
  16. Now we need to copy all of the modules in Step 13 into our working directory.
  17. Go to the drivers directory

    cd /lib/modules/2/kernel/drivers

    Note2: just press tab to fill in this bit, there will now be two kernels, use 2.6.29.6-0.24.smp.gcc3.4.x86_64 as this is the updated kernel that was installed during the update.

  18. Copy all of the modules in Step 13 to /tmp/b/lib.

    cp scsi/scsi_mod.ko /tmp/b/lib

    cp scsi/sr_mod.ko /tmp/b/lib

    cp scsi/sd_mod.ko /tmp/b/lib

    cp usb/host/ehci-hcd.ko /tmp/b/lib

    cp usb/host/uhci-hcd.ko /tmp/b/lib

    cp usb/host/ohci-hcd.ko /tmp/b/lib

    cp usb/storage/usb-storage.ko /tmp/b/lib

    cp /lib/modules/2.6.29.6-0.24.smp.gcc3.4.x86_64/kernel/lib/crc-t10dif.ko /tmp/b/lib

  19. Now let’s package the contents of the working directory /tmp/b into our new initrd-usb-update.img.

    cd /tmp/b

    find . | cpio –c –o | gzip -9 > /boot/initrd-usb-update.img

  20. Now all we need to do is edit the /boot/grub/menu.1st file to tell the kernel to use the new ramdisk that we just created. Remember that this new ramdisk is currently located in /boot/ (aka /dev/sda1) and is called initrd-usb-update.img.

    nano /boot/grub/menu.1st

  21. Find the line starting with initrd /vmlinux-…………………… and replace with

    initrd /initrd-usb-update.img

  22. Save the file and reboot the computer, remove the CD and allowing it to boot from the USB key. You now have your new updated Openfiler installation booting from the USB key directly.

Turn off flow control for SMB Clients

For better CIFS performance turn off your network adapter flow control. I can achieve a sustained 60 mb/s transfer between my Macbook and Openfiler once flow control is turned off. I was only achieving around 30 mb/s previously.

Turn off flow control for ESXi hosts using NFS/iSCSI to Openfiler

First understand what flow control is before performing the follow actions, the following articles provide good cases for either enabling or disabling flow control and auto-negotiation for flow control.

http://www.telecom.otago.ac.nz/tele301/student_html/ethernet-autonegotiation-flow-control.html – not to be confused with auto-negotiation of flow control.

http://virtualthreads.blogspot.com/2006/02/beware-ethernet-flow-control.html

Since this is my lab I’m going to disable flow control completely.

To do this on ESXi hosts follow these instructions or use VMware KB 1013413.

  1. Enable Remote SSH for the ESXi host first.
  2. Use your favourite SSH client and log in as root (assuming you can, disable lock-down mode etc).
  3. Run the following command to list all your vmnic interfaces, make a note of the vmnic that is used to connect to the Openfiler Server.

    esxcfg-nics –l

  4. In my case it’s just vmnic0 (I’m using a HP Microserver), type the following command to see the current flow control status of that adapter.

    ethtool –show-pause vmnic0

  5. Run the following commands to set auto-negotiation or RX flow control or TX flow control, any combination is possible.
  6. To disable flow control for sent and received traffic, use the command:

    ethtool –pause tx off rx off

  7. To disable auto-negotiation of flow control, use the command:

    ethtool –pause autoneg off

  1. Open the /etc/rc.local file using a text editor and append the same commands used in Step 6, placing each on its own line. Then save the file.
  2. For an ESXi host, save the configuration change using the command:

    /sbin/auto-backup.sh

    The commands added to the /etc/rc.local file will be executed at startup, persisting the configuration changes across reboots. As they are executed in Step 6, no reboot is required for them to take effect.

How to setup Active Directory authentication on Openfiler

Setup Active Directory Authentication

The steps must be performed in this order, otherwise you’ll get a headache trying to work out why you cannot see any Groups listed.

Go to Services | Enable SMB/CIFS server.

Click on SMB/CIFS Setup.

  1. Change the NetBIOS name to just the hostname of the server (do not include the domain).

Navigate to Accounts | Expert View. Configure for your environment, note the CAPITALIZATION of some of the fields.

Click on Use Kerberos 5 and enter your domain details, note the CAPITALIZATION of some of the fields.

Now click on Accounts | Group List and if done successfully, you should see your Domain groups.

How to install and run Openfiler on a USB key

Install Openfiler onto the USB Key

  1. Disconnect all hard disks from the server.
  2. Boot from the Openfiler CD and install Openfiler by invoking the linux expert command and installing as normal onto your USB key, taking into account your partitioning to fit onto your USB key and also making a record of which partitions are your /boot and your / partitions.

Create a new ramdisk that includes the USB drivers.

  1. When installation is complete, reboot the server with the Openfiler CD still in the drive and then type

    linux rescue

  2. Go through the menus and select your region and keyboard and skip the automatic mounting of your installed OS. We will do this manually.
  3. When the prompt appears, create a directory to mount the USB key.

    mkdir /mnt/sysimage

  4. Now mount the / of the USB key onto /mnt/sysimage.

    mount /dev/sda2 /mnt/sysimage

    Note: your / partition may be /dev/sda3 instead, depending on how you setup your partitioning during the installation of Openfiler.

  5. Now mount the boot partition of the USB key onto /mnt/sysimage/boot.

    mount /dev/sda1 /mnt/sysimage

    Note: your / partition may be /dev/sda1 instead, depending on how you setup your partitioning during the installation of Openfiler.

  6. Make the /mnt/sysimage your working environment by changing your root location so you are working on the file system on the usb key.

    chroot /mnt/sysimage

  7. Copy the current initrd file to a temporary location where we can work on it.

    cp /boot/initrd-1 /tmp/initrd.gz

    Note1: now’s a good time to press TAB

  8. Gunzip the initrd.gz file

    gunzip /tmp/initrd.gz

  9. Make a temporary working directory

    mkdir /tmp/a

  10. Go into the new working directory

    cd /tmp/a

  11. Extract the contents of the initrd file into /tmp/a.

    cpio –i < /tmp/initrd

  12. Now we edit the init file to load the USB and SCSI drivers for the new initrd-usb.img ramdisk.

    nano init

  13. Do a search for “mount –t proc /proc /proc” and add the following underneath this line. We want to load these USB and storage modules before any other modules that’s why these entries need to be at the top of the file.

    echo “Starting Openfiler on USB”

    echo “Loading scsi_mod.ko module”

    insmod /lib/scsi_mod.ko

    echo “Loading sr_mod.ko module”

    insmod /lib/sr_mod.ko

    echo “Loading sd_mod.ko module”

    insmod /lib/sd_mod.ko

    echo “Loading ehci-hcd.ko module”

    insmod /lib/ehci-hcd.ko

    echo “Loading uhci-hcd.ko module”

    insmod /lib/uhci-hcd.ko

    echo “Loading ohci-hcd.ko module”

    insmod /lib/ohci-hcd.ko

    sleep 5

    echo “Loading usb-storage.ko module”

    insmod /lib/usb-storage.ko

    sleep 5

  14. Do a search for insmod /lib/scsi_mod.ko, insmod /lib/sd_mod.ko, insmod /lib/ehci-hcd.ko and insmod /lib/uhci-hcd.ko and remove these duplicate entries from the rest of the file. We do not want these loaded again.
  15. Save the file and exit with CTRL X, then Y, or if you used vi then :wq!
  16. Now we need to copy all of the modules in Step 13 into our working directory.
  17. Go to the drivers directory

    cd /lib/modules/2/kernel/drivers

    Note2: just press tab to fill in this bit, you should only have one kernel.

  18. Copy all of the modules in Step 13 to /tmp/a/lib.

    cp scsi/scsi_mod.ko /tmp/a/lib

    cp scsi/sr_mod.ko /tmp/a/lib

    cp scsi/sd_mod.ko /tmp/a/lib

    cp usb/host/ehci-hcd.ko /tmp/a/lib

    cp usb/host/uhci-hcd.ko /tmp/a/lib

    cp usb/host/ohci-hcd.ko /tmp/a/lib

    cp usb/storage/usb-storage.ko /tmp/a/lib

  19. Now let’s package the contents of the working directory /tmp/a into our new initrd-usb.img.

    cd /tmp/a

    find . | cpio –c –o | gzip -9 > /boot/initrd-usb.img

  20. Now all we need to do is edit the /boot/grub/menu.1st file to tell the kernel to use the new ramdisk that we just created. Remember that this new ramdisk is currently located in /boot/ (aka /dev/sda1) and is called initrd-usb.img.

    nano /boot/grub/menu.1st

  21. Find the line starting with initrd /vmlinux-…………………… and replace with

    initrd /initrd-usb.img

  22. Save the file and reboot the computer, remove the CD and allowing it to boot from the USB key. You now have your Openfiler installation booting from the USB key directly.

New Openfiler for the VMwire lab

Openfiler is a very cool NAS/SAN product that is completely free. I just purchased some brand new SATA III controllers and disks so I’ve decided to migrate my storage from Freenas running on my HP Microserver to my old Dell PE SC440. Doing so will free up the HP Microserver to run vSphere and allow me to expand my current lab capacity of 1.7Tb to a whopping 7.4Tb. This article details my configuration steps and acts as a means for me to document my VMwire lab and I thought that others may benefit from my experience.

Hardware

 

Hardware

Make/Model

Details

Server

Dell PowerEdge SC440

Intel Pentium Dual Core E2180 2.0GHz, 8Gb RAM

Networking

Intel Corporation 82546EB Gigabit Ethernet PCI-X Dual Port Controller

Installed in PCI 33MHz slot

Embedded Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express Controller

Onboard

SATA III Controllers

2 x ASUS S3U6 Dual Port SATA III and Dual Port USB 3.0 PCI-E 2.0 x4 Contollers

One installed in PCI-E 2.0 x4 slot and the other in PCI-E 2.0 x8 slot

1 x HighPoint RocketRAID 620 Dual Port PCI-E 2.0 x1 SATA III Controller

Installed in PCI-E 2.0 x1 slot

Fibre Channel Controller

1 x Brocade 2340 Single Port 2Gb Fibre Channel PCI-X Adapter

Installed in PCI 33MHz slot

Boot Device

Kingston DataTraveller+ 2Gb USB Key

Openfiler boot device

Storage Disks

5 x Seagate ST2000DL03-9VT1 2Tb 5400RPM 64Mb Cache SATA III Disks

  

Installed OS

Openfiler NAS/SAN

2.6.26.8-1.0.11.smp.gcc3.4.x86_64 (SMP)

 

The Total SATA 3 ports is 6, plus an additional 4 SATA 2 ports from the onboard adapter.

I have disabled all the SATA 2 ports from within the BIOS as I will only be using the SATA 3 ports from the three Add-in cards to support my 5 Seagate disks in a RAID-5 aggregate.

Overview of the Openfiler Setup

I have already setup my Openfiler Server by following the instructions from https://vmwire.com/2011/06/12/how-to-install-and-run-openfiler-on-a-usb-key/ to install Openfiler onto the Kingston DataTraveller+ 2Gb USB Key. Networking is setup and everything is working nicely ready for the configuration of the new RAID-5 Array.

Below is a screenshot of the Openfiler Hardware Information.

Setting up the Software RAID

I’m using software RAID due to the fact that SATA III RAID Controllers with 5 or more ports are currently still very expensive. The HighPoint RocketRaid 630 and the ASUS S6U3 Controllers are relatively cheap and can be picked up for less than £20 each.

  1. You can view the list of block devices available to use on Openfiler by navigating to Volumes | Block Devices.

Openfiler has successfully picked up the 5 new disks and we can now manage them.

To set up the Software RAID we must first partition the disks as “RAID array member” partitions.

To do this you must click in each of the block devices and create a “RAID array member” partition. Remember to leave /dev/sda alone as this is the boot device.

  1. Clicking on /dev/sdb brings up the partitioning page.
  2. Select RAID array member from the Partition Type drop down menu and then just click on Create.

Continue creating the partitions on the remaining four disks by repeating Step 1.

Once complete the Block Device Management should look something like this.

Now we are ready to create the RAID Array. To do this we need to navigate to Volumes | Software RAID and create the array.

I’m going to create a RAID-5 (parity) array with a 64kB chunk size.

The Seagate disks only have about 1.82Tb usable capacity, so a RAID-5 array with 5 disks would give a total of 7.4Tb usable capacity.

Setting up the Volume Group

We can create the Volume Group by navigating to Volumes | Volume Groups.

I’ve decided to create a single volume group for all my services – CIFS, NFS, iSCSI and FC. We will then create Volumes from this single Volume Group to carve up the storage. The resulting Volume Group Management page will then look something like this.

That’s our Volume Group setup complete. You would never need to revisit the Volume Group Management page ever again, unless you either rebuild your disks or create new Volume Groups from new disks. For reference the path for this Volume Group is /dev/md0/volg_raid5/.

Setting up a new Volume

Now we can start carving up our 7.4Tb usable capacity by creating Volumes and then assigning these Volumes to specific services.

We can manage this by using the Add Volume page. I’m going to add a new 1Tb NFS volume for my VMware virtual machines.

To do this navigate to Volumes | Add Volume.

Upon creating this new Volume, the path for this Volume will then be /dev/md0/volg_raid5/nfs01/.

Setting up a new Sub-folder on a Volume

Now that we have created a Volume, we can now create a Sub-folder in which we can make a Share. I’m going with a 1:1 allocation of Volume to Sub-folder in my lab, so the naming conventions reflect this.

To do this, navigate to the Shares page. The screen should be similar to this.

We can create the new Share by clicking on the VMware Virtual Machines link.

Now we can create a new sub-folder, I’m going to call mine nfs01-vm01.

The Shares page will now display the following.

Setting up a new Share

To create the actual nfs01-vm01 NFS share that is mounted on our vSphere servers we need to make the share from the Sub-folder created in “Setting up a new Sub-folder from a Volume”.

  1. Click on the nfs01-vm01 link and then click on the Make Share button.
  2. Select the “Public guest access” radio button and click on Update.

  1. Now scroll to the bottom of the page and click on the “RW” radio button underneath the NFS column, and then click on Update.

Note that you need to have setup network access configuration prior to doing any of these steps. This is not covered in this guide.

Again, for reference this nfs01-vm01 NFS share for use by VMware vSphere hosts has a path of /mnt/volg_raid5/nfs01/nfs01-vm01/.

Mounting the NFS share

The NFS volume is now ready to be mounted by VMware vSphere hosts. Just use /mnt/volg_raid5/nfs01/nfs01-vm01 as the “Folder” mount point.

Happy days!

[NEW]

Setting up a new Volume for CIFS

Now I can start carving up my remaining 6.4Tb usable capacity by creating Volumes and then assigning these Volumes to specific services. For this part I’m going to create a new Volume for CIFS.

We can manage this by using the Add Volume page. I’m going to add a new 3Tb CIFS volume for my Windows file storage.

To do this navigate to Volumes | Add Volume.

Upon creating this new Volume, the path for this Volume will then be /dev/md0/volg_raid5/cifs01/.

Setting up a new Sub-folder on a Volume for CIFS

Now that we have created a new Volume for CIFS, we can now create a Sub-folder in which we can make a Share. I’m going with a 1:1 allocation of Volume to Sub-folder in my lab, so the naming conventions reflect this.

To do this, navigate to the Shares page. The screen should be similar to this.

We can create the new Share by clicking on the Windows File Share.

Now we can create a new sub-folder, I’m going to call mine cifs01-smb01.

The Shares page will now display the following.

Setting up a new Share for CIFS

To create the actual cifs01-smb01 CIFS share that can be used for SMB file storage we need to make the share from the Sub-folder created in “Setting up a new Sub-folder on a Volume for CIFS”.

  1. Click on the cifs01-smb01
    link and then click on the Make Share button.

  1. Select the “Controlled access” radio button and click on Update.

  1. Now scroll to the Group access configuration section in the middle and select the primary group for this CIFS share and also set Read or Read/Write Permissions for this share based on your Active Directory Groups. I’ve already created a Security Group called “openfiler cifs users” with which my AD account VIRTUAL\Hugo.Phan is a member of. Once done click Update.

    Note that to use Active Directory authentication, you must set up Authentication under the Accounts section. I’ve written a guide here https://vmwire.com/2011/06/13/how-to-setup-active-directory-authenticaton-on-openfiler/.

  1. Now scroll all the way down to the bottom and configure the Host access configuration to the /mnt/volg_raid5/cifs01/cifs01-smb01/ Volume. Choose the options relevant to your environment, I’m making this share R/W accessible by all my devices in my network – 192.168.200.0/24. Then just click on Update to finish.

 

Note that you need to have setup network access configuration prior to doing any of these steps. This is not covered in this guide.

Again, for reference this cifs01-smb01 CIFS share for use as network file storage over the network has a path of /mnt/volg_raid5/cifs01/cifs01-smb01/.

Connecting to the SMB Share

The SMB share is now ready to be used by client computers. To connect just open a UNC path to it. of.virtual.local is the FQDN of my Openfiler Server.

Now enter your domain credentials.

Job done!

VMware Tools RPM Installation with PXEBOOT and Kickstart

Purpose

This article explains how to use the Operating System Specific Packages (OSPs) to install VMware Tools during the PXEBOOT and Kickstart of a Linux guest OS running on vSphere 4.1 and above.

Background

As of vSphere 4.1, the VMware Tools RPMs are no longer available on the CD image linux.iso. To install you must use the tar.gz package and install it manually.

To quote the vSphere 4.0 U2 release notes:

“The VMware Tools RPM installer, which is available on the VMware Tools ISO image for Linux guest operating systems, has been deprecated and will be removed in a future ESX release. VMware recommends using the tar.gz installer to install VMware Tools on virtual machines with Linux guest operating systems.”

This future ESX release is indeed vSphere 4.1. The reason that the RPM packages are no longer available on the VMware Tools CD image for Linux guest operating systems ISO is to reduce the footprint of ESXi. Therefore the linux.iso no longer contains the RPM installer.

Not only is this a real pain for customers who have always deployed packages onto their Linux guests with RPMs but also removing the VMware Tools RPM also causes issues with the deployment of Linux guests through PXEBOOT and Kickstart methods.

Yes, you could argue that there is the option of using vCenter Templates along with Customization Specifications (CS) for Linux, and I for one love the fact that the CS works for Linux very well. This is not always an option for a customer who has already configured their entire environment to deploy both ESXi servers and virtual machine guests with PXEBOOT and Kickstart.

The only option here is to perform manual installations of VMware Tools using the tar.gz file which is included with vSphere 4.1. This of course poses a few issues.

One: this is a repetitive task which is both time consuming and problematic if the number of new VMs to provision is high.

Two: some security conscious organisations do not allow the gcc Compiler and/or the Linux Kernel sources to be installed on the VM guests. Both the gcc Compiler and the Linux Kernel sources are mandatory for the successful installation of VMware Tools using the tar.gz file.

Three: if the guest VM is using a VMXNET2 or VMXNET3 ethernet adapter, then the guest VM will not have compatible drivers if VMware Tools is not installed.

These are just three of the reasons that I’ve seen in the wild, there are more but I won’t go into much detail here.

So how do we go about solving this?

Have a read of KB article 1024047: ESXi 4.x does not include RPM format for VMware Tools.

The solution here is to use the Operating System Specific Packages (OSPs). VMware Tools OSPs allow you to use your operating system’s native update mechanisms to automatically download, install, and manage VMware Tools for the supported operating systems. For more information regarding OSPs, see http://www.vmware.com/download/packages.html.

For this guide, we are referring to RHEL’s yum update mechanism.

This guide details how you can use the http://www.vmware.com/pdf/osp_install_guide.pdf to prepare your Build Server to enable the automated deployment of VMware Tools during a guest RHEL in a PXEBOOT environment.

Resolution

For this guide, I will be using the Ultimate Deployment Appliance 2.0 (uda20.build17) to deploy a RHEL 5.5 x64 virtual machine.

First we need to prepare to install the operating specific packages (OSPs) for RHEL 5 guest operating systems on the Build Server. We do this by preparing the directory structure for the rpms, and placing these in the correct location on the Build Server for the guest VM to download during a Kickstart installation.

Perform the following on your workstation.

The OSPs are located on the VMware Tools packages Web site at http://packages.vmware.com/tools.

  1. First download the entire directory that contains the package relevant to your operating system, for this guide I will be using the RHEL x86_64 packages located at http://packages.vmware.com/tools/esx/4.1u1/rhel5/x86_64/index.html.

     

  2. Clicking on this link will give you the following list of files.

  3. Do a right-click Save-As and save these files to a location of your choice. I settled for a folder called vmwaretools on my Desktop.

     

  4. Also create a folder within vmwaretools called repodata, and also download the files from http://packages.vmware.com/tools/esx/4.1u1/rhel5/x86_64/repodata into your vmwaretools/repodata directory.

     

  5. Once these two tasks have been complete you will see the following directory contents of vmwaretools.

  6. And the contents of vmwaretools/repodata.

  7. Now you will need to download the VMware Packaging Public Keys.

     

  8. Create a directory called keys within vmwaretools/

     

  9. Point your web browser to http://packages.vmware.com/tools/keys and download all of the files into your vmwaretools/keys directory.

     

  10. The contents of the keys directory should look like this

     

  11. You should now have a vmwaretools folder structure that looks like this

     

  12. Now copy the entire vmwaretools directory to your Build Server using your favourite SCP application. I’m using the UDA 2.0, so I will be placing vmwaretools in /var/public/www/kickstart/rhel/. “rhel” is the ‘Flavor’ name that I called my RHEL 5 OS configuration.

Perform the following on the Build Server.

  1. On the UDA 2.0 the contents of the /var/public/www/kickstart/rhel/vmwaretools directory should now look like this.

     

  2. If you navigated to http://<ip_address_of_uda/kickstart/rhel/vmwaretools/, you should be able to see the same folder structure. If you can’t then you may need to do a chmod 755 on the vmwaretools directory and its contents.

     

  3. Now edit your kickstart file to look something like this.

    %post

    # Import the VMware Packaging Public Keys from the Build Server.

    rpm –import http://%5BUDA_IPADDR%5D/kickstart/%5BTEMPLATE%5D/vmwaretools/key/VMWARE-PACKAGING-GPG-DSA-KEY.pub

    rpm –import http://%5BUDA_IPADDR%5D/kickstart/%5BTEMPLATE%5D/vmwaretools/key/VMWARE-PACKAGING-GPG-RSA-KEY.pub

    # Create and edit the VMware repository directory and file, note that this points to the Build Server during Kickstart build. Once VMware Tools is installed we shall change the baseurl to point to the VMware OSP URL.

    # Add the following contents to the repository file and save

    cat > /etc/yum.repos.d/vmware-tools.repo <<\EOF1

    [vmware-tools]

    name=VMware Tools

    baseurl=http://192.168.200.30/kickstart/rhel/vmwaretools

    enabled=1

    gpgcheck=1

    EOF1

    # Install VMware Tools by accepting all defaults

    yum install -y vmware-tools

    # Delete the customised vmware-tools.repo file and reconfigure with the baseurl to point to the VMware OSP URL for RHEL5 64-bit.

    rm –f /etc/yum.repos.d/vmware-tools.repo

    cat > /etc/yum.repos.d/vmware-tools.repo <<\EOF2

    [vmware-tools]

    name=VMware Tools

    baseurl= http://packages.vmware.com/tools/esx/4.1u1/rhel5/x86_64

    enabled=1

    gpgcheck=1

    EOF2

  4. I have attempted to use the VMware Packaging Public Keys from the VMware OSP repository URL but this does not work, anyone care to enlighten me in the comments below?

    I tried this:

    # Import the VMware Packaging Public Keys

    rpm –import http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub

    rpm –import http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub

     

  5. I also attempted to use the VMware OSP URL directly in the vmware-tools.repo file without luck either. If you can get this to work then please comment below and I’ll update the post.

You should now be able to deploy a guest Linux VM running on vSphere ESXi 4.1 through PXEBOOT and Kickstart and have the VM automatically install VMware Tools. Plus, all future updates of VMware Tools can just be done by invoking a yum install -y vmware-tools.

Enabling VMXNET 3 for PXEBOOT and KICKSTART of RHEL Virtual Machines

Purpose

This guide shows you how to create a new initrd.img with integration for the VMXNET3 driver to allow guest RHEL virtual machines equipped with the VMXNET 3 driver to Kickstart build RHEL using PXEBOOT.

Background

VMware’s VMXNET 3 network adapter supports PXE booting but RHEL 5 does not have a driver that supports network installations using the default initrd.img.

If you tried to perform automated installation using kickstart with the standard initrd.img you will see the following screen:

 

This is because Anaconda does not recognise the VMXNET 3 device and therefore is not able to load a driver for it.

This guide shows you how to create a new initrd.img with integration for the VMXNET3 driver.

For the impatient few, I’ve made the resulting initrd.img.vmxnet file available for download, it is a clean ramdisk image that was made using the steps below.

It is the PXEBOOT RAMDISK with the VMXNET3 driver for RHEL5 (created from the rhel-server-5.5-x86_64-dvd) [2.6.18-194.el5].

Tested and working to support VMXNET3 in Anaconda.  You can download it from here initrd.img.vmxnet and then jump all the way to Step 18 to place it on your Build Server.

Prerequisites

Prepare a Reference Virtual Machine

First create a new reference virtual machine with the following hardware specifications:

Configuration Value
VM Hardware Version Hardware Version 7
Network Adapter VMXNET 3
SCSI Controller LSI Logic SAS
SYSTEM .vmdk Device SCSI 0:0 15Gb
Remove Floppy Device Yes

Install RHEL (rhel-server-5.5-x86_64-dvd) by mounting the ISO to the VM and then perform a manual installation of VMware Tools. This will give you the reference virtual machine with which you will then use to copy the vmxnet.ko and vmxnet3.ko from.

Enable sshd services on the Reference VM by typing:

/etc/init.d/sshd start

This will make it a lot easier to copy files to your Build Server.

Prepare your Build Server

Create your own PXEBOOT and Kickstart installation or use one that you already have. For my example I will be using the Ultimate Deployment Appliance 2.0 (uda20.build17).

Most of the configuration is done on Build Server so by all means enable SSHD to make things a lot easier for you.

My Build Server IP is 192.168.200.30.

Integrating VMXNET 3 into initrd.img

At this point you should have SSH access to both your Build Server and your Reference VM.

Perform the following on the Build Server.

1.    Make some working directories to work in

mkdir /tmp/workingdir

mkdir /tmp/workingdir/initrd

mkdir /tmp/workingdir/modules

Perform the following on the Reference VM.

2.    Obtain the initial ramdisk initrd.img from the pxeboot directory, this file can be obtained from the rhel-server-5.5-x86_64-dvd ISO file which should still be connected to the Reference VM. The initrd.img file can be found in the images/pxeboot directory.

3.    Mount the ISO image

mount /dev/cdrom /media

4.    Copy the initrd.img to the Build Server

scp /media/images/pxeboot/initrd.img root@192.168.200.30:/tmp/workingdir/

5.    We now need to ascertain the PCI and Device ID of the VMXNET 3 network adapter by first running

Lspci

        Note that our VMware VMXNET3 Ethernet Controller lives on 0b:00:0

6.    With this information we can obtain the HEX number for the device by running

lspci –n

Note the HEX value for device 0b:00.0 is 15ad:07b0.

Perform the following on the Build Server.

7.    Unpack the initrd.img file to allow us to amend the ramdisk, you should be in /tmp/workingdir/initrd/

zcat ../initrd.img | cpio –id

 

8.    Extract the modules.cgz archive from within the initrd subdirectory

cd /tmp/workingdir/modules

zcat ../initrd/modules/modules.cgz | cpio –id

Perform the following on the Reference VM.

9.    Copy the vmxnet*.ko modules from the Reference VM over to the Build Server. The vmxnet*.ko files are located in /lib/modules/2.6.18-194.el5/misc

scp /lib/modules/2.6.18-194.el5/misc/vmxnet*.ko root@192.168.200.30:/tmp/workingdir/modules/2.6.18-194.el5/x86_64/

10.    Copy the modules.alias file from the Reference VM to the Build Server for use later on. This file contains the vmxnet entries and is located at /lib/modules/2.6.18-194.el5/

scp /lib/modules/2.6.18-194.el5/modules.alias root@192.168.200.30:/tmp/workingdir/initrd/modules/modules.alias.reference

Perform the following on the Build Server.

11.    Change permissions for the two new vmxnet*.ko files, you should be in /tmp/workingdir/modules/2.6.18-194.el5/x86_64/

chmod 744 vmxnet*

12.    Pack up the new modules.cgz which now includes the vmxnet*.ko modules and create a new cpio archive to replace the old modules.cgz.

cd /tmp/workingdir/modules

find . | cpio -o -H crc | gzip -9 > /tmp/work/initrd/modules/modules.cgz

    After a few seconds the operation will complete.

13.    Modify the pci.ids file with an entry for the VMXNET 3 adapter.

cd /tmp/workingdir/initrd/modules

nano pci.ids

14.    Search for VMware and add the following line under the Abstract SVGA Adapter

07b0    VMware Adapter

    The 07b0 number here is whatever was obtained from Step 5 above.

15.    Edit the module-info file and add the following entries for the VMXNET and VMXNET 3 Adapters, put it in under ‘v’ to keep it in alphabetical descending order. You should still be in /tmp/workingdir/initrd/modules/

nano /tmp/workingdir/initrd/modules/module-info

vmxnet

    eth

    “VMware vmxnet Ethernet driver”

 

vmxnet3

    eth

    “VMware vmxnet3 Ethernet driver”

16.    Import the vmxnet entries from the Reference VM’s module.alias file (now called module.alias.reference) into the Build Server’s module.alias file.

grep vmxnet /tmp/workingdir/initrd/modules/modules.alias.reference >> /tmp/workingdir/initrd/modules/modules.alias

The contents of the new module.alias file should look like this.

17.    Package the new initrd.img ramdisk up with all the changes done above.

cd /tmp/workingdir/initrd

find . | cpio -o -H newc | gzip -9 > /tmp/workingdir/initrd.img.vmxnet

18.    Copy the new initrd.img.vmxnet into the PXEBOOT environment. On UDA2.0 this location is /var/public/tftproot/

cp /tmp/workingdir/initrd.img.vmxnet /var/public/tftproot/

19.    Edit your PXEBOOT configuration to use the new initrd.img.vmxnet file instead of the standard initrd.img file. My example uses the UDA.

cd /var/public/conf/templates/

nano rhel.dat

20.    On the line CMDLINE=, edit the initrd= entry to point to the new initrd.img.vmxnet instead.

CMDLINE=ks=http://[UDA_IPADDR]/kickstart/[TEMPLATE]/[SUBTEMPLATE].cfg initrd=initrd.img.vmxnet ramdrive_size=8192

21.    That’s it, now PXEBOOT a VM and it will now be able to Kickstart using the VMXNET3 network adapter.