Nov 202016
 

Warning! If you have added custom indexes to the VMware vCenter database, you will need to remove them completely before you can complete a vCenter 6.5 upgrade. If they are still present in the database, the upgrade wizard throws an error.

vcenter65_01

The error file tells you specifically which indexes it does not like. The error file is found at:

C:\Users\(youraccount)\AppData\Local\Temp\vcsUpgrade\vcdb_req.err

You’ll find the error message towards the bottom of the document. My specific item was:

1 [42000](50000) [Microsoft][SQL Server Native Client 11.0][SQL Server]ERROR ! Extra indexes: VPX_EVENT.HFX_VPX_EVENT_Cover01; VPX_STAT_COUNTER.IX_VPX_STAT_COUNTER_STAT; VPX_TASK.HFX_VPX_TASK_Cover01;

Drop the indexes and retry the upgrade and it should get past this point without a problem.

Such is the risk we all take with modifying the databases underneath third party software…

May 122014
 

Ever since it was released, the vSphere Web Client is not the most responsive of web GUIs. After some digging, you can work around it to boost the responsiveness! It looks like the Java-based front-end is a bit starved for memory under the covers. Now, YMMV and it might put you in an unsupported state, but tinker if you wish.

On your vCenter server, edit the wrapper.conf file at:

c:\program files\vmware\infrastructure\vspherewebclient\server\bin\service\conf

Change:

wrapper.java.maxmemory=1024m

to

wrapper.java.maxmemory=3000m

Feb 032014
 

Recently I encountered a small glitch while trying to install VMware’s vCenter 5.5.0b Server on a new VM with Windows Server 2012R2 on it. Now, this OS is not yet ‘certified’ by VMware for use, but it’s pretty close to Windows Server 2012, and they will support it soon enough, so why not use it? But, a quirk with the differences between Windows Server 2012 and 2012R2 prevents a successful installation. Read on to see how to fix this.

windows server 2012 r2 logovmware

Continue reading »

Jan 282014
 

OK, so maybe they do not lie to you, but I got your attention. In virtualized environments, the performance statistics that you see from the management interface may not give you the entire picture, and can lead to bad assumptions or misleading recommendations.

Remember, the virtualization layer does not understand the nuances of the applications that you are running inside the virtual machine, so it might be giving you performance statistics that are not representative of that application. 

For example, SQL Server is very memory hungry, as it uses memory to cache data reads from disk. If you give a SQL Server virtual machine 32GB of vRAM, and allocate 26GB to the SQL Server buffer pool, chances are that all 26GB is going to get consumed as your workload reads data. However, the physical host server where your VM is running might not understand this usage pattern, and might misinterpret things. 

Take this scenario. I recently had to load a 20GB dataset into a SQL Server for performance statistic analysis. The data is read from disk and inserted into a new SQL Server table. At the end of the load, and because nothing else was running on that server at the time of the load, almost all of the inserted data was also now in the buffer pool. But, look at what the VMware performance counters for memory for this virtual machine reported.

vmware stats active memory during bulk data load

You’ll notice that the active memory counter grows as the data is loaded. Once the data is loaded, however, the data resides in the buffer pool, but VMware is reporting that the memory is no longer active as the timer on the block deltas grows. During this time, I am actively performing the analysis of the data, so the data is still being read from, but just does not change. This activity is not reflected in the counter at all.

It’s not just memory either. LogicMonitor has a great writeup of the differences between Windows Perfmon sampling inside a VM versus the actual CPU usage, as reported by the physical server. 

I have heard virtualization administrators tell DBAs that because these counters show that most of the memory is stale and not active, it’s OK for them to reduce the amount of memory allocated to that virtual machine.  This counter is pretty misleading, and I see quite a bit of misinterpretation by virtualization administrators on this topic. Now, they should not be expected to know the specifics on the workloads executing in their environments, but understanding that this counter does not show you the entire picture is going to save everyone a lot of time during these types of discussions.

As a result, this disparity is just one of the reasons why I constantly push the process of actively collecting ongoing performance statistics from both the physical host and from inside the guest, as well as from within the application that you have running inside the VM. Correlate everything together to see the full picture of what is going on, because any single metric probably does not give you the complete picture.

UPDATE:  (t) from VMware has previously written a great blog post on vmware.com discussing this exact topic, and he goes into greater detail on the counter. You should go check it out here!

Sep 302012
 

I sat down this afternoon after being out of town for week to work on a few things in my recently upgraded vSphere 5.1 lab and found that vCenter Server was offline. The service would not start.

Odd. It was working great when I left, and nothing changed in the lab…

A quick check of the Event Log had a nonspecific service failure with nothing useful. The database server showed it was working just fine. Restarting vCenter did nothing. It was time to start the deep dive.

A quick look at the vCenter service logs, (not) intuitively stored under the folder C:\ProgramData\VMware\VMware VirtualCenter\Logs, showed some strange entries. The VPXD log showed the following entries.

The culprit was found in the following lines.

Failed to add LDAP entry cn=(global id),ou=Instances,dc=virtualcenter,dc=vmware,dc=int: 0x68 (The object already exists)

Error while adding service-instance entry cn=(global id), ou=Instances,dc=virtualcenter,dc=vmware,dc=int

It looked like it was something related to LDAP, but the OU information was foreign. It looks like it was trying to insert an object that already existed. That’s quite silly that it needed to .

A quick check of the VMware knowledge base yielded nothing specifically for this error, but showed that I could find the specific details for this internal reference in the Windows Server 2008R2 ADSI Edit module. To get into the local ADAM server, enter the following settings.

The error said it could not insert a service instance entry, so I looked under the entries tree item. I found two instances under it. Having to disable entries in here from time to time, I renamed both instances and then restarted the instance.

Boom. It started right up. It then was allowed to re-register a new instance, as you can see above, and life looks good. I restarted the service a few times and it bounced like it should always do.

*sigh* That was not exactly how I wanted to spend a Sunday afternoon, but such is life. I’m still not sure why this particular event decided to occur while I was gone, nor do I have anything in the system that tells me why, but at least it is resolved.

SO – if you ever see those errors, now you know how to fix it. Bounce your vCenter Management Webservices and your vCenter Update Manager services after you make these changes so that everything propogates.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close