Wednesday, March 13, 2013

Installting libvirt on Ubuntu 12.04.2 LTS for ESX

After listening to the vBrownBag podcast on OpenStack I was eager to try out libvirt, a toolkit to manage virtualization. I primarily use Ubutu and so fired up putty and installed libvirt via Ubuntu's package management tool, aptitutude. I was surprised (and dismayed) that Ubuntu's packaged version of libvirt does not support ESX.  Upon trying out virsh I was greeted with the error:
error: invalid argument in libvirt was built without the 'esx' driver
I turned to Google and found Launchpad bug 565771 and a reference to the libvirt package listserv. It appears that the Ubuntu package maintainer has declined to include support for the libvirt ESX driver unless someone steps forward to maintain it.

My favorite Linux distribution is Ubuntu for a number of reasons. After using Debian for a number of years Ubuntu's updated packages was welcome relief.  If an updated package was unavlabile on Debian the only recourse was to build from source and so I am familiar with make and stow.  I encourage you to check out stow if you compile frequently from source. Drawing on this experience I set out to compile libvirt from source on Ubuntu 12.04.2 LTS.

First I needed some pre-requisite development libraries.
aptitude update && aptitude install -y stow libxml2-dev libdevmapper-dev libpciaccess-dev python-dev libnl-dev libcurl4-openssl-dev

I downloaded libvirt to /usr/local/src, untared the archive and configured the source.
./configure --with-esx --prefix=/usr/local

Next I ran make and make install with one adjustment. Since I am using stow to keep the installation separate I wanted to use the install option "prefix=/usr/local/stow/libvirt".  I am not 100% on the make process but it appeared some libraries needed to be installed and libtool didn't like that I was using the "prefix" option.

I turned to Google once again and found this listserv thread on using stow. It was recommended to use DESTDIR to work around this issue.
make
make install DESTDIR=/usr/local/stow/libvirt


Next I used stow to install the package under /usr/local
cd /usr/local/stow
stow -d /usr/local/stow -t / libvirt


After installing I needed to run ldconfig before using virsh to pick up any new libraries installed.
ldconfig


At this point we're all set to run virsh!
virsh -c esx://host.local?no_verify=1
Enter username for host.local [root]:
Enter root's password for host.local:
Welcome to virsh, the virtualization interactive terminal.
Type:  'help' for help with commands
       'quit' to quit
virsh #

Active Directory server unavailable causes VMware SSO failure

Had an interesting issue today with VMware Single Sign On (SSO) Server where it failed to authenticate connections. I saw the following in the SSO log located at C:\Program Files\VMware\Infrastructure\SSOServer\logs\ssoAdminServer.
[2013-03-13 07:41:49,575 ERROR opID=10d57a6f-20e6-4621-ba44-e90ae7cd8751 pool-31-thread-7  com.vmware.vim.sso.admin.vlsi.PrincipalDiscoveryServiceImpl] Error connecting to the identity source
com.rsa.common.ConnectionException: Error connecting to the identity source
 Caused by: javax.naming.NamingException: getInitialContext failed. javax.resource.spi.ResourceAdapterInternalException: Unable to create a managed connection 'ldaps://<REDACTED>:3269' with 'GSSAPI' Reason: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection <REDACTED>:3269 [Root exception is javax.resource.spi.ResourceAdapterInternalException: Unable to create a managed connection 'ldaps://<REDACTED>:3269' with 'GSSAPI' Reason: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection <REDACTED>:3269]
 Caused by: javax.resource.spi.ResourceAdapterInternalException: Unable to create a managed connection 'ldaps://<REDACTED>:3269' with 'GSSAPI' Reason: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection <REDACTED>:3269
 Caused by: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection <REDACTED>:3269
 Caused by: javax.naming.CommunicationException: <REDACTED>:3269 [Root exception is java.net.ConnectException: Connection timed out: connect]
 Caused by: java.net.ConnectException: Connection timed out: connect
What's interesting is that we have two Active Directory servers specified in the SSO configuration, Server-A and Server-B.  There were only errors for Server-B in the SSO log.  Server-B is currently unavailable, currently undergoing an upgrade to Windows Server 2012.

Seeing the errors in the log I restarted the VMware SSO Service. Within a few minutes the service was running and working again. Logins were working again and I could see that Server-A was being used.

Curious, I checked our SSO settings for the domain and confirmed that Server-A was set to "Primary" and Server-B was "Secondary". Why didn't SSO automatically switch to using Server-A if Server-B could not be contacted?

Not sure why Server-A was not automatically used but the log clearly indicated the error and restarting the SSO service worked.