VMware Cloud Community
computerguy7
Enthusiast
Enthusiast
Jump to solution

New vCenter 4.1 server has "check new notifications" task queued a lot

Any ideas why I would see like 30 tasks in my vCenter console showing "check new notifications" with a status of Queued? See screenshot.

Reply
0 Kudos
1 Solution

Accepted Solutions
Troy_Clavell
Immortal
Immortal
Jump to solution

I'm pretty sure it has something to do with VMware Update Manager. As you can see in your screen shot it shows a queued item for "download patch definitions" I would try and restart your VUM service and see what happens.

View solution in original post

Reply
0 Kudos
18 Replies
Troy_Clavell
Immortal
Immortal
Jump to solution

Probably VUM?

Reply
0 Kudos
computerguy7
Enthusiast
Enthusiast
Jump to solution

What does VUM stand for?

Reply
0 Kudos
Troy_Clavell
Immortal
Immortal
Jump to solution

VMware Update Manager. You have it installed in your environment, and if so, did you update it when you updated vCenter?

Reply
0 Kudos
computerguy7
Enthusiast
Enthusiast
Jump to solution

This is a new vCenter server. We decided not to upgrade, we created a new one.

Reply
0 Kudos
Troy_Clavell
Immortal
Immortal
Jump to solution

I'm pretty sure it has something to do with VMware Update Manager. As you can see in your screen shot it shows a queued item for "download patch definitions" I would try and restart your VUM service and see what happens.

Reply
0 Kudos
computerguy7
Enthusiast
Enthusiast
Jump to solution

I restarted the service and so far the message hasn't showed up again.

On an unrelated note, does running the "services.sh restart" from the cli console on a ESXi 4.1 host affect the virtual machines running on that host?

Reply
0 Kudos
Troy_Clavell
Immortal
Immortal
Jump to solution

I restarted the service and so far the message hasn't showed up again.

Glad to see you got it resolved!

On an unrelated note, does running the "services.sh restart" from the cli console on a ESXi 4.1 host affect the virtual machines running on that host?

no, this will have no impact on any running guests.

Reply
0 Kudos
computerguy7
Enthusiast
Enthusiast
Jump to solution

services.sh restart does appear to restart the HA service, which means that host may not send an HA heart beat for a few seconds or minutes (depending on service restart time). So this is probably a bad idea for a ESX host in an HA environment running guests, correct?

Reply
0 Kudos
Troy_Clavell
Immortal
Immortal
Jump to solution

no, this will not cause an HA event. As long as the other ESX Hosts in the environment have heartbeat to each other, you will be fine. It will not affect any networking components.

Reply
0 Kudos
computerguy7
Enthusiast
Enthusiast
Jump to solution

This is good to hear, but I will have to test. I am skeptical. Given the amount of experience you appear to have I should just take your word for it, but I like to see things my self.

Reply
0 Kudos
computerguy7
Enthusiast
Enthusiast
Jump to solution

I got an email from vCenter saying my host was down when I restarted the services (services.sh restart) earlier. This was when my host had no VM's running and while it was in maintenance mode, and it still triggered some alerts. This is why I think restarting the services while in production will trigger some events and alerts.

Reply
0 Kudos
Troy_Clavell
Immortal
Immortal
Jump to solution

the host going into a not responding state is normal, as you are restarting a few things, including hostd.

Test as you may, I promise you though, restarting the management agents will not trigger an HA event.

mrkelder
Contributor
Contributor
Jump to solution

Had the same problem and found this post, but still no solution to the issue.

What did work is:

Be sure all you clients are updated to the latest build of vSphere Client.

The Client download link on thevSphere webpage can point to an older build of the Client.

So download the latest build from VMware.com and replace this "VMware-viclient.exe" with the one you downloaded. (rename needed)

Located @ C:\ProgramData\VMware\VMware VirtualCenter\docRoot\client

This resolved the issue in our enviorment.

I hope this helps some people resolve the same thing...

Reply
0 Kudos
beovax
Enthusiast
Enthusiast
Jump to solution

I had this other day, tried all sorts restarting the VC adn VUM services etc etc

In the end I went into the VUM configuration settings and just changed the notification schedule. This killed all the outstanding queued tasks and the next one completed all OK. FIngers crossed this problem is now solved. It was getting very annoying with so many stuck in the task list

Reply
0 Kudos
allencrawford
Enthusiast
Enthusiast
Jump to solution

I've had this happen in our 4.1 environments as well.  It doesn't happen very often, but when it does, I'll see around 30 of these tasks queued up but they all error out as soon as I log into the server with the vSphere Client (w/VUM plugin enabled).  Just happened the other day actually.  It is almost like that "check new notifications" task can only be completed when someone with the VUM plugin enabled is connected to the vCenter/VUM server.  So when none of our admins are connected, it may be queuing up, but as soon as one of us connects and the next scheduled check hits, all the pending ones immediately error out and the latest check then works fine.  Weird.

Reply
0 Kudos
mark_chuman
Hot Shot
Hot Shot
Jump to solution

Check to make sure you have a 32bit DSN allocated for VUM.  If you did setup VUM on a 64bit DSN and don't have a 32bit DSN setup you would have VUM errors upon logging in though.  This combination could occur if you setup a 64bit DSN for VUM pre upgrade and then deleted the 32bit DSN post upgrade (ie, the upgrade install used the 32bit DSN and not the 64bit DSN).

Reply
0 Kudos
Threonine
Contributor
Contributor
Jump to solution

I'm getting this same issue.  Definitely agreed it resolves itself when you're logged in with a vSphere Client running the VUM plug-in.

This is what happens when you login with the vSphere client with the VUM plug-in.  Prior to that it just hangs indicating the task is queued.

VUM issue.png

I've confirmed the 32-bit system DSN is already setup.  I may have some authentication issues going on...  I'm going to be rebuilding this server shortly.  So we'll see if the problem recurs.

Reply
0 Kudos
wgbeatty
Contributor
Contributor
Jump to solution

For me, this was a simple but embarrasing fix.  Set up a new workstation for myself and had the VSphere Client installed.  Saw lots of these "check new notifications" messages in the Recent Tasks list and tried some of the suggestions such as restarting the VUM service with no success.  Then tried looking at the plug-ins and realized the Update Manager plug-in wasn't installed on my workstation...voila, problem solved 🙂

Reply
0 Kudos