Posts Tagged ‘workaround’

h1

In-the-Lab: NexentaStor and VMware Tools, You Need to Tweak It…

February 24, 2012

While working on an article on complex VSA’s (i.e. a virtual storage appliance with PCIe pass-through SAS controllers) an old issue came back up again: NexentaStor virtual machines still have a problem installing VMware Tools since it branched from Open Solaris and began using Illumos. While this isn’t totally Nexenta’s fault – there is no “Nexenta” OS type in VMware to choose from – it would be nice if a dummy package was present to allow a smooth installation of VMware Tools; this is even the case with the latest NexentaStor release: 3.1.2.

I could not find where I had documented the fix in SOLORI’s blog, so here it is… Note, the NexentaStor VM is configured as an Oracle Solaris 11 (64-bit) virtual machine for the purpose of vCenter/ESXi. This establishes the VM’s relationship to a specific VMware Tools load. Installation of VMware Tools in NexentaStor is covered in detail in an earlier blog entry.

VMware Tools bombs-out at SUNWuiu8 package failure. Illumos-based NexentaStor has no such package.

Instead, we need to modify the vmware-config-tools.pl script directly to compensate for the loss of the SUNWuiu8 package that is explicitly required in the installation script.

Commenting out the SUNWuiu8 related section allows the tools to install with no harm to the system or functionality.

Note the full “if” stanza for where the VMware Tools installer checks for ‘tools-for-solaris’ must be commented out. Since the SUNWuiu8 package does not exist – and more importantly is not needed for Illumos/Nexenta – removing a reference to it is a good thing. Now the installation can proceed as normal.

After the changes, installation completes as normal.

That’s all there is to getting the “Oracle Solaris” version of VMware Tools to work in newer NexentaStor virtual machines – now back to really fast VSA’s with JBOD-attached storage…

SOLORI’s Note: There is currently a long-standing bug that affects NexentaStor 3.1.x running as a virtual machine. Currently there is no known workaround to keep NexentaStor from running up a 50% cpu utilization from ESXi’s perspective. Inside the NexentaStor VM we see very little CPU utilization, but from the performance tab, we see 50% utilization on every configured vCPU allocated to the VM. Nexenta is reportedly looking into the cause of the problem.

I looked through this and there is nothing that stands out other that a huge number of interrupts while idle. I am not sure where those interrupts are coming from. I see something occasionally called volume-check and nmdtrace which could be causing the interrupts.

Nexenta Support

A bug report was reportedly filed a couple of days ago to investigate the issue further.

h1

vSphere Client in Windows7

September 4, 2009

Until there is an updated release of the VMware vSphere Client, running the client on a Windows7 system will require a couple of tricks. While the basic process outlined in these notes accomplishes the task well, the use of additional “helper” batch files is not necessary. By adding the path to the “System.dll” library to your user’s environment, the application can be launched from the standard icon without further modification.

First, add the XML changes at the end of the “VpxClient.exe.config” file. The end of your config file will now look something like this:

  <runtime>
    <developmentMode developerInstallation="true"/>
  </runtime>
</configuration>

Once the changes are made, save the “VpxClient.exe.config” file (if your workstation is secured, you may need “Administrator” privileges to save the file.) Next, copy the “System.dll” file from the “%WINDOWS%\Microsoft.NET\Framework\v2.0.50727” folder on an XP/Vista machine to a newly created “lib” folder in the VpxClient’s directory. Now, you will need to update the user environment to reflect the path to “System.dll” to complete the “developer” hack.

To do this, right-click on the “Computer” menu item on the “Start Menu” and select “Properties.” In the “Control Panel Home” section, click on “Advanced system settings” to open the “System Properties” control panel. Now, click on the “Environment Variables…” button to open the Environment Variables control panel. If “DEVPATH” is already defined, simply add a semi-colon (“;”) to the existing path and add the path to your copied “System.dll” file (not including “System.dll”) to the existing path. If it does not exist, create a new variable called “DEVPATH” and enter the path string in the “Variable Value” field.

System-Properties-Environment-Panel-Windows7

The path begins with either %ProgramFiles% or %ProgramFiles(x86)% depending on whether or not 32-bit or 64-bit Windows7 is installed, respectively. Once the path is entered into the environment and the “System.dll” file is in place, the vSphere Client will launch and run without additional modification. Remember to remove the DEVPATH modification to the environment when a Windows7 vSphere Client is released.

Note that this workaround is not supported by VMware and that the use of the DEVPATH variable could have unforseen consequences in your specific computing environment. Therefore, appropriate considerations should be made prior to the implementation of this “hack.” While SOLORI presents this information “AS-IS” without warranty of any kind, we can report that this workaround is effective for our Windows7 workstations, however …