Monthly Archives: October 2012

Running nested ESXi –the real inception

Posted by on October 28, 2012 No comments

Nested ESXi servers are essentially virtualised ESXi servers.  They can be quiet fun to play with.  Usually the only reason you’d do this is for a test lab.  You don’t need a physical ESXi server to nest virtual ESXi hypervisors.  You can choose your product of choice.

In my case I’m running VMware Workstation 9 and virtualised ESXi 5.1 as the second level and then running virtual guests as a third level within the virtual ESXi.  In Workstation 9 you have the ability to connect to ESXi hosts and view guest VMs --as below.

You don’t need to do anything special to virtualize ESXi.  In fact there’s an option to select ESX as the guest OS in VMware Workstation 9.

When you turn on a virtual ESXi guest (or is it a host???) a message appears in the bottom right corner of the console.  It’s pretty self-explanatory.  You can create a 32-bit guest VM only on this ESXi server.

The cool cats that VMware are, allow you to run 64-bit VM guests too with a small config change.  The feature is only available in ESXi 5 and above.

On the virtualised ESXi guest enable console access (or SSH) and login as root.  The file ‘config’ in /etc/vmware needs to be modified and an additional line add, ‘vhv.allow = “TRUE”’.

If you’re a VI fan go ahead and use that.  If you’re lazy like me you can just append it to the file with echo.


echo 'vhv.allow = "TRUE"' >> /etc/vmware/config

Once the change is made no reboot is necassary.  You will now be able to run 64-bit guest VMs within your already virtualised ESXi host.  In an extreme example I ran another ESXi guest at the third level to prove a 64-bit OS would run.  On a second virtualised ESXi guest I’m just running a 32-bit Linux VM at that same third level.

For my test lab three levels is as deep as I need to go.  I’ve read that it’s also as deep as you can go as guest VMs will fail to run at a fourth level.  I don’t have the resources to test this out in my lab.  I heard that there was a VMworld presentation on multiple level nesting ESXi servers.  Would certainly be worth finding.

 

Appendix

As with many things VMware, nested ESXi is not officially supported.
VMware Link:  Support for running ESX/ESXi as a nested virtualization solution

I had trouble with the vmxnet3 network drivers with the nested ESXi.  Instead I chose to go with E1000 particular for that third level.

EqualLogic MultiPathing Extension Module – Alternative Install

Posted by on October 20, 2012 3 comments

UPDATE: If you’re looking for step-by-step instructions to install the EqualLogic Multipathing Extension Module click HERE to go to my most recent post on the topic.  

UPDATE: Note that the ESXCLI command below  —depot has a double dash.

I recently ran into an issue where vSphere 5.1 Update Manager scans and detects the latest Dell EqualLogic Multipathing Extension Module 1.1.1 as Not Applicable for ESXi 5.1 and will not select the patch during a Remediate.  Below I show how to install this extension via the ESXCLI.

If you’re running a DELL EqualLogic SAN with ESX you should be running DELL’s Multipathing Extension Module (MEM).  MEM is a Path Selection Plugin (PSP) driver for ESX.  In fact no matter what SAN you have you should investigate if they have a PSP driver for ESX.

ESX have three built-in pathing options, (Most Recently Used, Round Robin, and Fixed).  By installing EqualLogic’s MEM you get a fourth option called DELL_PSP_EQL_ROUTED.  EqualLogic PS Series SANs can run Active / Active pathing.  By installing the MEM, ESX can be made aware of this and can load balance appropriately.  This can all lead to increase in bandwidth utilisation and lower network latency.

Since ESX4 I’ve been installing the EqualLogic MEM using VMware Update Manager through the vCenter C# client.  I’ve never had any issues right up until and including ESXi 5 Update1.  The process is quite simple.

  1. Import the MEM as a patch.
  2. Create a new Baseline with a Host Extension and add the MEM extension that was imported. (EqualLogic have different versions for each ESX version so be mindful).
  3. Attach the baseline to the Host
  4. Perform a Scan and Remediate the ESX host.
  5. Reboot.

As mentioned in the beginning, Update Manager 5.1 saw the patch at Not Applicable.  I took this as an opportunity to try and install the patch through the ESXCLI.  To do this I used VMA.  If you’re not running or haven’t tried the VMware Management Assistant (VMA) it’s worth looking into.  It’s a nice convenient way to get CLI access to all your ESX hosts.

To install a PSP driver the host needs to be in Maintenance Mode.  So do this first or you’ll get a similar error to below.

Next transfer the EqualLogic Multipathing files to a location on the ESX host you want to install to.  In my case below I installed them to a folder on datastore1.

Back on the VMA use the ESXCLI and enter the following command, substituting the file location for your own, to install.

Esxcli —server=my_esx_host.domain software vib install —depot /vmfs/volumes/datastore1/EqualLogic-ESX-Multipathing-Module/dell-eql-mem-esx5-1.1.1.270268.zip

This is a kernel driver and a reboot is required for the PSP driver to successfully apply.  Once a reboot is performed the new PSP becomes the default selection.

Now selecting a datastore and selecting pathing you can see a new pathing option and it’s selected by default.  You will also see that all paths to the LUN are Active.

Appendix

Most recent step-by-step MEM installation article EqualLogic Multipathing Extension Module – Installing

Installing vSphere 5.1 – vCenter Inventory Service

Posted by on October 8, 2012 No comments

To install vCenter Server the vCenter Inventory Service is a prerequisite.  I was going to gloss over the fact that I know nothing about the Inventory Service, current or previous version, but still thought it best to raise that fact.  There is just so little information out there on it.  Having recently done my VCP there was no mention of this function.  VMware’s website has excellent technical documents but they fall short on explaining anything to do with the Inventory Service.  For a component that is so predominant in the installation process it’s surprising.

The only explanation I have on it is what’s on the installation screen 🙂  Make of it what you will.

“vCenter Inventory Service stores vCenter Server application and inventory data, enabling you to search and access inventory objects across linked vCenter Servers.”

To begin the installation mount the vSphere media and run the installer.  Select the option to install VMware vCenter Inventory Service.

Fight your way through the license and patent agreement screens as usual.  Then click next to start the Installation wizard.

In my case I am upgrading my previous vSphere 5 version but a clean install is virtually identical with the exception of the below screen which prompts to either do not override or replace the database.  I’ve chosen to not override.

Enter in your FQDN of the local system.  In most, bar large installations, this will be the same system as your SSO and vCenter host.  If you’ve read my previous post on SSO and FQDN (http://wp.me/p1BmCN) you’ll know that DNS records are extremely important for a proper working SSO and vCenter implementation.

Accept all the default ports.  Unless you have security concerns or you’re traversing firewalls there’s little reason to change them.

Select the best size of your ESX environment.  Try to foresee what your future requirements will be and match that.  In my case I’ve selected medium.

This next screen relates to the new Single Sign On feature of vSphere 5.1.  Leave the default administrator user and enter in your master password you set during the installation of Single Sign On.  For the Lookup Service URL enter in your SSO server.  This will most likely be the same host.  Use the FQDN and the port.  By default the localhost is filled in so hopefully no change will be needed.

Next you’ll be presented with a Self-Signed certificate.  To proceed click Install certificate.

That’s all.  A little simpler than Single Sign On DB creation and installation.  Next you can finally install the vCenter Server with the prerequisites out the way.

vSphere 5.1 SSO and the FQDN issue

Posted by on October 4, 2012 No comments

During the installation of the vSphere 5.1 Single Sign On component you will be prompted for the Fully Qualified Domain Name or IP of the server you are installing on.  If the server you are installing to does not have a DNS record the installation will fail and rollback.

More often than not you’ll have a forward lookup record for your host.  The SSO installation, however, will also perform a reverse lookup query on your IP.  If you don’t have a reserve record you will be prompted that the installation could not fully resolve the host and the installation may fail (I can tell you it WILL fail).

It’s important to check that the host you are using has both a forward and reverse record.

The vSphere SSO installation seems to take it one step further and query every interface on the server.  If you have multiple interfaces to different networks the installation will query the forward and reserve on all interfaces.  If records don’t exist for all these interfaces the installation will fail.  For the life of my I can’t figure out why this is import for all interfaces.

In my situation I had numerous interfaces on my blade server.  Particularly two iSCSI interfaces with no DNS records.  The installation would not let me proceed with a successful installation till they were fully resolvable or disabled.  It’s also worth noting that if you have link local addresses (i.e. 169.254.x.x) that they will be queried too and fail the installation.

You can confirm if the installation of SSO is failing by looking at the vm_ssoreg.log logfile under your user profile folder.

{system drive}users{username}AppDataLocalTempvm_ssoreg.log