Category Archives: vCenter

Quickly configuring vCenter alarms using PowerCLI

To quickly configure all vCenter alarms to send an email, use this snippet:

Get-AlarmDefinition | New-AlarmAction -Email -To '[email protected]'

Once that is in place, set up an AlarmActionTrigger to send an email when the monitored item moves from green to yellow. The default AlarmAction created earlier already contains a setting for moving from yellow to red:

Get-AlarmDefinition | Get-AlarmAction -ActionType SendEmail | where-object {$_.To -like '[email protected]'} | New-AlarmActionTrigger -startstatus 'Green' -EndStatus 'Yellow'

To have the alarm action repeat, use the -Repeat flag on the New-AlarmActionTrigger.

To add other transitions, use the New-AlarmActionTrigger and change the -StartStatus and -EndStatus to the desired transition. For example, -StartStatus ‘Red’ -EndStatus ‘Yellow’ will set the alarm to notify “Once” when moving from Red down to Yellow.

To see all Alarms configured to send to a certain email address along with triggers:

Get-AlarmDefinition | Get-AlarmAction -ActionType SendEmail | Where-Object {$_.To -like '[email protected]'} | Select AlarmDefinition,To,Trigger

To remove all SendEmail AlarmActions for a particular email address:

Get-AlarmDefinition | Get-AlarmAction -ActionType SendEmail | where-object {$_.To -like '[email protected]'} | Remove-AlarmAction

Further information at https://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.powercli.ug.doc%2FGUID-3758D090-C799-4BA0-8F6C-1C2E7A055D1B.html

View Admin dashboard for vCenter Server 5.1 displays the message: VC service is not working properly

Regarding VMware KB: View Admin dashboard for vCenter Server 5.1 displays the message: VC service is not working properly, I encountered this when upgrading a vCenter 5.0 host to 5.1.

When it was all said and done, I checked the View 5.1.3 console and found the vCenter objects in a red error state, saying the service was not working properly.

I edited the vCenter server in View and it gave me the incorrect username/password. Since that is one of the issues in the KB, I followed the steps to move the View domain to be above the System domain in SSO.

Seems like an obvious thing to do for a new SSO installation – wish the SSO installer would have done this.

Once moved, the vCenter objects turned green and provisioning was able to run.

Troubleshooting vCenter database connection

We are testing out the latest VMware View release, 4.5, and during an uninstall of an older release, somehow the vCenter service lost its connection to the SQL Server 2005 Express database that we are using and it would not start.

After some poking around, the vCenter log (C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs\vpxd-*.log) contained these telling lines:

[2010-09-15 09:14:55.354 03728 info ‘App’] [Vpxd::ServerApp::Init:759] Calling: VpxdVdb::Init(Vdb::GetInstance(), false, false)
[2010-09-15 09:14:55.354 03728 error ‘App’] ODBC error: (IM002) – [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
[2010-09-15 09:14:55.354 03728 error ‘App’] Error getting configuration info from the database
[2010-09-15 09:14:55.354 03728 error ‘App’] [Vpxd::ServerApp::Init] Init failed: VpxdVdb::Init(Vdb::GetInstance(), false, false)
[2010-09-15 09:14:55.354 03728 error ‘App’] Failed to intialize VMware VirtualCenter. Shutting down…
[2010-09-15 09:14:55.354 03728 info ‘App’] Forcing shutdown of VMware VirtualCenter now

Poking around the VMware Knowledge Base, I found the article 1003928: Troubleshooting the database data source used by VirtualCenter Server which mentions the registry key “HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter\DB”.  The value for the key “1” was blank, meaning no DSN was specified. I changed the value to our System DSN “vcenter”.

Next I opened up odbcad32 to actually look at the “vcenter” System DSN but could not open it because the SQL Native Client 10.0 driver was missing! I downloaded it from the Microsoft SQL Server 2008 Feature Pack, August 2008 and installed it and then was able to open the DSN. I found that the “Server” field was simply set to “localhost” and when I tried to test the connection, it timed out. I looked at the old ViewComposer DSN and it had a server and instance specified – “VIEW45-VC\SQLEXP_VIM”. I put this in the “vcenter” DSN and then with integrated Windows authentication, I was able to change the default database to “VIM_VCDB” and test the connection and it succeeded. I saved the DSN and attempted to start the vCenter service. This time it started and stayed running and the logs looked good.

VMware KB wins again!

vCenter

Upgrading to vCenter 4.1

Like a lot of folks, I was excited with the release of vCenter 4.1 and ESX(i) 4.1. Lots of great new features, some bugfixes, and the overall feeling of “ooh, new shiny things to play with!”

Every new release of vCenter/ESX is like Christmas morning as there are plenty of new features to be discovered and bugs fixed that streamline previous operations.

I was dismayed at first to read that vCenter required a 64-bit OS as not too long ago I had built up a nice pair of vCenter 4.0 servers on Windows Server 2003 Standard (32-bit) and liked the way they were working. I was running SRM 4.0 along with Update Manager and everything was working great.

I knew that with the 64-bit requirement, I might as well go to Windows Server 2008 R2 64-bit for my two vCenter servers, but I had some hurdles to jump over. Specifically, we aren’t really running any Server 2008 machines in-house, save for those that we have to experiment and kick the tires with. So I decided to build a Server 2008 template and then deploy a pair of new vCenter servers from that.

The process of building a new template VM has been documented widely across the virtualization blogosphere, but I shall throw my two cents in the ring with a post describing my own win2k8 template. But as usual, that is for a later time.

The other hurdle to leap over, in addition to getting Server 2008 set up for production use, was the fact that I was going to have to relocate my vCenter servers to brand new machines. I tried this once awhile ago with VirtualCenter 2.5 and the results were diastrous. So I was not encouraged with the fact that I was going to have to try to move again.

Luckily, the VMware team understood that a lot of people would be in the same boat due to their 64-bit-only requirement so they put together a set of python scripts to aid in the moving of vCenter to a new host.

The guides that I referred to during this upgrade are:

I started out by stopping my vCenter services, backing up the Microsoft SQL 2008 Standard databases for VC and SRM, and then detaching and copying them to the new vCenter servers where I already had Microsoft SQL 2008 Standard  64-bit installed. I attached the DBs and made sure my SQL “vpxuser” account was set to owner.

Then I created a 64-bit System DSN for the vCenter database by running “odbcad32” at the Run command. I also created a 32-bit System DSN for SRM by running c:\windows\sysWOW64\odbcad32 at the Run command (thanks to boche.net for that tip)

A side note: my VUM database is part of my vCenter database, so I didn’t have to create a DSN for that – it will just piggyback on top of the vCenter DSN as it did on my Server 2003 vCenter servers.

After my DSNs were created, I followed the instructions in the Upgrade Guide to copy the datamigration folder off the vCenter 4.1 ISO on to my 32-bit server and ran the “backup.bat” to backup my vCenter certificates and other configuration that lives outside the database. It also backed up my VUM and Orchestrator configuration (even though I don’t use Orchestrator).

I copied the resulting datamigration folder to the new host. It now has “data” and “log” folders that hold the backed up configuration. I ran “install.bat” on the new host and pointed it to my vCenter 4.1 media. One thing that got me at first was it prompted for the Update Manager media path and I gave it what I thought was the path – the Update Manager folder inside the vCenter installer, but that was incorrect and I had to end up giving it the same path that I gave for vCenter. It would be nice if it would just check there first for the Update Manager installer files and then only prompt if it can’t find them.

Then the datamigration install.bat file launched the vCenter installer and I stepped through that, changing the install path to the E:\ drive that I had set up for it and pointing it to the DSN that I had configured. I also allowed it to automatically update the ESXi/vCenter host agents. Soon the installer finished and then also launched the VUM one. I stepped through that as well, again changing the path to E: and pointing it to the DSN that it needed.

The VUM install was also successful and then datamigration install.bat utility ended. I didn’t even get to see any of the host agents being updated because when I got the client installed and logged in, everything looked great. I had a few servers that needed to be reconfigured for HA but other than that, the install went great.

I repeated this process on my 2nd vCenter host and it went well too.

I did have to break up my linked-mode config as it sort of stopped working – I could log in to one server and see both, but if I logged in to the other one, it would only show that one and an authentication failed message for the other one. I had to “force” it to isolate itself from linked-mode, but I think that was because the vCenter service hadn’t stopped in time. But 2nd time was a charm and after joining them back together, all was well.

I then installed SRM 4.1, paying careful attention to the release notes (linked earlier) describing how to relocate SRM to a new server with a new name. I installed the HP EVA Storage adapter and visited my SRM config to make sure it was OK. It was but I did have to reconfigure the EVA credentials. I don’t know if they were lost or what but it was no big deal. I ran a test recovery plan and that worked perfectly.

I then reconfigured VUM to not download VM patches for Windows or Linux and none for ESX3. I also added the ESX4.0 to 4.1 upgrade zip and created a baseline for upgrading all my ESXi 4.0 hosts to 4.1.

Finally I remembered to copy the sysprep files off my 2k3 vcenter servers so that we can continue deploying/customizing 2k3 and XP server VMs.

At this point, everything looks great and I’m heading home. ESXi upgrade next week!

Fixing vCenter Linked Mode

I recently had a problem with one of my two vCenter servers in linked mode. When using the vSphere client to connect to this particular server, the client would not show the hosts/VMs or anything about the 2nd vCenter server.

But when connecting with the client to the 2nd vCenter server, it would show both vCenter servers and their hosts/VMs.

So obviously something is up with the first vCenter server. I ran the Linked Mode setup again and it acted like it wasn’t linked, which was how it appeared. So I went through the prompts to set up the linked mode and when it came down to actually setting it up, it would fail. It did this twice. Looking at the log that it mentioned, it was complaining that the vCenter Server service was not stopped. It had successfully stopped the Web Access service, but not vCenter Server.

I loaded up services.msc and went to stop the vCenter server service but was prompted that our Site Recovery Manager service would also need to be stopped. After agreeing and stopping both services, the Linked Mode configuration completed successfully and started the vCenter Server and Web Access services. It did not however start the Site Recovery Server service.

At this point it looks like the Linked Mode configurator needs to understand about other services that depend on vCenter Server and track them to stop/start before/after the linked mode is configured.

I don’t know why the vCenter server became unlinked from the 2nd one, but it works good now!