10-08-2012 04:21 AM
Hi all -
So i'm getting these log messages repeatedly:
2012 Oct 8 07:01:17 vsm-01 %VMS-5-CONN_CONNECT: Connection 'vcenter' connected to the vCenter Server.
2012 Oct 8 07:01:17 vsm-01 %VMS-5-CONN_DISCONNECT: Connection 'vcenter' disconnected from the vCenter Server.
2012 Oct 8 07:04:17 vsm-01 %VMS-5-CONN_CONNECT: Connection 'vcenter' connected to the vCenter Server.
2012 Oct 8 07:04:17 vsm-01 %VMS-5-CONN_DISCONNECT: Connection 'vcenter' disconnected from the vCenter Server.
2012 Oct 8 07:07:16 vsm-01 %VMS-5-CONN_CONNECT: Connection 'vcenter' connected to the vCenter Server.
2012 Oct 8 07:07:17 vsm-01 %VMS-5-CONN_DISCONNECT: Connection 'vcenter' disconnected from the vCenter Server.
2012 Oct 8 07:10:16 vsm-01 %VMS-5-CONN_CONNECT: Connection 'vcenter' connected to the vCenter Server.
2012 Oct 8 07:10:16 vsm-01 %VMS-5-CONN_DISCONNECT: Connection 'vcenter' disconnected from the vCenter Server.
2012 Oct 8 07:13:16 vsm-01 %VMS-5-CONN_CONNECT: Connection 'vcenter' connected to the vCenter Server.
2012 Oct 8 07:13:16 vsm-01 %VMS-5-CONN_DISCONNECT: Connection 'vcenter' disconnected from the vCenter Server.
i've searched and dug as much as I could and the troubleshooting guide basically asks you to run the command to 'show svs connections', which I do, and it shows as not connected when i enter the command:
connection vcenter:
ip address: x.x.x.x
remote port: 80
protocol: vmware-vim https
certificate: default
datacenter name: xxxxx
admin:
max-ports: 8192
DVS uuid: -
config status: Enabled
operational status: Disconnected
sync status: -
version: -
vc-uuid: -
I'm not having any config push problems, and when we create a new veth port-profile for a cust, it immediately appears in vCenter just like always. No customers are reporting any problems, and our lead on the VM and server side sees no error messages in vCenter that would indicate a problem.
Any Ideas?
system image file is: | bootflash:/nexus-1000v-mz.4.2.1.SV1.5.1.bin |
system compile time: | 1/30/2012 17:00:00 [01/30/2012 21:49:49] |
Solved! Go to Solution.
10-08-2012 05:38 AM
Your disconnects are almost exactly 3mins apart.
Check the following:
-"show core" on the VSM - see if there are any crashed processes
-using "show sys red status" about 4 mins apart, see if the active/standby role is flapping between your primary & seoconday VSM.
Where is the VSM's datastore? On a local server or shared LUN?
Regards,
Robert
10-08-2012 05:38 AM
Your disconnects are almost exactly 3mins apart.
Check the following:
-"show core" on the VSM - see if there are any crashed processes
-using "show sys red status" about 4 mins apart, see if the active/standby role is flapping between your primary & seoconday VSM.
Where is the VSM's datastore? On a local server or shared LUN?
Regards,
Robert
10-08-2012 06:43 AM
Hi Robert,
Thanks for your reply. So, checking what you mentioned, I have:
vsm-01# sho cores
Module-num Instance-num Process-name PID Core-create-time
---------- ------------ ------------ --- ----------------
2 1 vms 3683 May 8 04:29
2 1 vms 6883 Jul 5 08:32
2 1 vms 10531 Sep 1 13:50
and with the redundancy, I checked this over that time frame, and no flaps. The datastore is on a LUN.
Thanks,
James
12-10-2012 04:47 PM
All -
I Just wanted to update this in case anyone else had any issues similar to this. A while back, we deployed another instance of a VSM in another goegraphically seperate DC. When we did, we believe that that particular VSM's configuration was slightly different from the one mentioned above with regard to the datacenter name under SVS connections. I had found in one of the deeper log files that the VSM mentioned above was telling me that the DC we had defined under SVS didn't exist. We dug through the MOB and sure enough found that the DC name was different. The new name matched the name we used when we deployed our latest instance of the VSM, and the name we used when deploying the VSM this post starts off with didn't match that.
We looked back through our captures (we video capture our more complex deployments) and as best as we can figure, the DC name was updated by the last VSM we deployed because our capture show that name as being defined when we were deploying that instance. This was news to us as we were'nt aware that deploying a VSM would update the DC name in the MOB.
02-24-2014 06:43 PM
Just wanted to say THANK YOU! for posting your solution. Your solution was a tremendous help to me in finding a solution to a similar issue I was having!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide