Mike's Realm

I was recently updating my home lab and ran into an issue with my NICs as VMware no longer has the Realtek 8168 drivers embedded in the ESXi installer for 5.5/6.0.  I tried the old method of injecting the driver into the ISO and that proved unsuccessful since the driver is blacklisted — with the release of vSphere 6.0 VMware has implemented a driver blacklisting feature.  Fortunately you can bypass this feature to get your home lab up and running: Read the rest of this entry »

So you changed the IP for your auto deploy server and re-registered it with vCenter but still having problems connecting with your vSphere Client?  You’ll see in the error message it has the old IP:

What you need to do is update the auto deploy config XML file, to find this file run the following command:

reg.exe QUERY “HKLM\SOFTWARE\WOW6432Node\VMware, Inc.\VMware vSphere Auto Deploy” /v DataPath

Then navigate to that path and find the vmconfig-autodeploy.xml file, pop it open in your favorite text editor and update the IP address in the <serviceAddress> declaration (highlighted below)

Save the file and restart the Auto Deploy service and you’ll be cooking once again!

So your kicking off your vSphere 5.5 upgrade and your starting off with vShield Manager and what should be a real easy upgrade you instantly get this error when you upload the Upgrade Bundle:

Fortunately the fix is super simple, just rename to ensure the file extension is .tar.gz e.g.:

Downloaded file: VMware-vShield-Manager-upgrade-bundle-5.5.0-1317534.gz
Renamed file: VMware-vShield-Manager-upgrade-bundle-5.5.0-1317534.tar.gz

It’s worth noting that this was also an issue with vShield Manager 5.1 as well if you were performing an upgrade…

Working with vCenter Orchestrator and getting “Error: Not published webview error The webview ‘weboperator’ is not published.” when you try to approve a user interaction in your workflow?

Navigate to Web Views and right click weboperator and ensure it’s published!

These updates were posted on the vCenter Orchestrator forums recently, if you aren’t keeping tabs over there you should be.

• vCO-Powershell-Plug-in -1.0.1 – kerberos support added
• vCO-SQL-Plug-in -1.1.0 – two related plugins combined with auto-generation as well as advanced SQL scripts. A few important issues fixed.
• vCO-vCenter-Plug-in – 5.0.1.1 – Critical update. Fixes a major issue with performance and losing attributes value. Update should be performed!
• vCO-VUM-Plug-in – 5.0. – The new version of the plugin that supports the VUM 5.0 version of the product.
• vCO-SNMP-Plug-in – 1.0.1 – Minor fix in relation to vCO policies listening for SNMP traps.

Links for each plugins release notes can be found on the thread @ http://communities.vmware.com/thread/405928?tstart=0

Wrote this article almost 6 months ago…finally got around to finishing it–Let me know what you think!

“Project AppBlast will provide the universal delivery of any application, including Windows-based applications, to any off-the-shelf browser or device supporting HTML 5, enabling instant remote access to non-HTML based applications.”

We discussed this at work the other day and we were excited at the possibilities with AppBlast, but since it’s not here now we’ll have to wait for a released product.  One of my co-workers Chad Wintzer said well why wait?  We dug around and came up with a working solution–and a damn good one after a few evenings grinding away at this.  Having a fair amount of RDS experience already this is what we came up with:

Backend

The backend infrastructure is provided by Microsoft’s Remote Desktop Services: RemoteApp.  This feature was introduced in Windows Server 2008 and was improved upon even more in the R2 release.  What RemoteApp allows you to do is run applications on backend RDS (TS) servers, and establish an RDP session from a user to just that app.  The user is presented with a window over their local desktop and functions just about as if it was actually installed and running off the local desktop.  Users can run multiple applications in parallel and so long as the app behaves well in a RDS environment you can host 1 installation with multiple users.  The servers that run RemoteApps are called RD Session Hosts, to scale you can simply throw a bunch of RD Session Hosts together and strap a load balancer on top, however you will want to use RD Connection Broker(s) in place of a traditional load balancer to keep track of user sessions.  The Connection Broker(s) manage session information such as RD Session Host server, session state, session ID, and the user associated with the aforementioned bits.  For the security junkies it’s worth noting that RemoteApp is AD integrated so you can restrict access to various apps via Security Groups.  This was something added in R2 I believe as many folks were complaining about this when RemoteApp first came out.

If you don’t want to go that route you can look at Citrix’s XenApp offering, but we found RDS: RemoteApp performed exactly as we needed it to. Read the rest of this entry »

So you find yourself in a position where you need to update one (or more) of your hosts but don’t have vCenter Update Manager around to assist.  In my case trying to get Windows Server 8 CP working….It’s not terribly difficult, you simply:

1. Download the patch – you can download patches direct from VMware @ the Patch Portal
2. Open a datastore with enough freespace to store the patch via your vSphere Client (Right-Click->Browse on a datastore)
3. Upload the patch you downloaded (should be a .zip file)
4. SSH into the host
5. Execute the command “esxcli software vib install /vmfs/volumes/<DATASTORE-NAME>/<PATCH-NAME>.zip”  – replacing the <DATASTORE-NAME> and <PATCH-NAME> appropriately.

This command can take some time to execute for large patches.

When it’s done you should get some text like below, remember to pay attention to this text so you know if you need to reboot your host or not.

Dell introduced this plugin awhile back, it’s actually a Virtual Appliance you import into vCenter.  The plugin inside vCenter is actually an Adobe Flex (Flash-based) app that gets embedded into your vSphere Client, so ensure you have Flash installed on the machine(s) you wish to use this plugin from.

Overview of Features

• Update BIOS/Firmware on Dell ESXi hosts from vCenter

• Checks for updates automatically and alerts you when there are updates available
• Can leverage an established Dell Repository to avoid data duplication–if you are a heavy Dell shop you should know what this is

• These Alarms can even trigger hosts to go into maintence mode to evacuate VMs from that particular host if the hardware event is critical (in a DRS enabled cluster of course)

• Works without (the God-awful) SilverStreak to automatically create support cases with Dell when issues arise

• Allows you to configure a proxy, if your environment requires one

• This leverages Dell Lifecycle Controllers and iDRACs to provision Dell servers somewhat auto-magically.
• First you create a Hardware Profile from a Reference Server–(configures boot order, BIOS settings, iDRAC settings, RAID config)
• Then you create a Hypervisor profile–You point at an ISO, and configure the vCenter, destination container (data center or cluster), and even a host profile for you enterprise plus users.
• Note you can “white-list” service tags so only those hosts you define can be used by the plugin to deploy against.

• So you can launch directly to your OSMA web console to connect to an OSMA agent on an ESXi host

• Does not require replacement by deploying a new OVF when a new version comes out

Read the rest of this entry »

I was setting up a new instance of Orchestrator inside my lab and came across this issue.  the Orchestrator Server service would not start, andi nside the vCenter Orchestrator Configuration webpage, we don’t have any output in the log–so we investigate the Windows logs…

In the system log all you see is Error: The VMware vCenter Orchestrator Server service terminated with service-specific error Incorrect function..

Poking around we come across a log file @ C:\Program Files\VMware\Infrastructure\Orchestrator\app-server\bin\wrapper.log which sheds some light on the problem:

Your first thought might be disk space, did a log run away? No that isn’t the case–Java Heap refers to memory, looking inside the wrapper.conf from the command above we find more information.

Java has to allocate 2Gb of RAM on startup. My VM only had 1.5Gb, that looks like the issue–this is what you get for ignoring the Minimum System Requirements (assuming your running Orchestrator on same server as your vCenter).  Increase the RAM on your VM and this error should be gone. vCenter Server should have a minimum of 3Gb of RAM.

My most favorite keyboard shortcut in the vSphere Client is Ctrl+Shift+F – It’s like Google for vCenter. It flips to the search box and allows you to find VMs, Templates, Datastores, Networks, Hosts, Clusters, Folders,etc.

vCenter Navigation Shortcuts

These shortcuts are for when you are in the a VM’s Console

VM Console Shortcuts

These shortcuts are for when you are in the a VM’s Console

New Item Shortcuts

Use these shortcuts to create new things in vCenter

VM Shortcuts

These shortcuts are for when you select a VM or are in the a VM’s Console