VMware Communities : Document List - VMware vCenter™ Server

Automatically backup SQL-Express database

Mon, 16 Nov 2009 15:15:12 GMT

Using the following procedures you can implement an automatic backup of your SQL-Express database:

1. Paste the following SQL-Script in an editor and save as backupsql.sql (for example):

BACKUP DATABASE VIM_VCDB /* select database for backup */
TO DISK = 'D:\backup\vcenter-db\VIM_VCDB.bak' /* select destination for backup */
WITH INIT; /* overwrite existing backup files */

2. Create a new job in "Accessories" -> "Scheduled Tasks" to execute the SQL script:

"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE" -S serverName\instance -E -i D:\backup\sqlbackup.sql

-S (this specifies the server\instance name for SQL Server)
serverName (this is the server\instance name for SQL Server)
-E (this allows you to make a trusted connection)
-i (this specifies the input command file)

Some helpful general information about backing up SQL Server can be found here:

http://www.simple-talk.com/sql/backup-and-recovery/sql-server-2005-backups/

Physical vs VM vCenter Server

Thu, 12 Nov 2009 05:30:19 GMT

Over the yeas there have been some controversy over this topic. Should vCenter Server be a physical or a virtual machine?

But it's also very important understand with VMware service require a working vCenter Server:

VMware HA require vCenter only for the initial setup
VMware VMotion and SVMotion require vCenter only to start the operation
VMware DRS/DPM can work only with vCenter
Template provisiong require vCenter

In addition, you will also need to know where your SQL server is located, cause if you loose DB connection, the vCenter Server service will stop!
For this reason in medium/small environment could be a good idea put the on the same server also the DBMS.

Physical solution: pro and cons

Pro

With VI 3.x the license server can work also if ESX are down... this coul be useful to power on the ESX and the VM
It is not susceptible to a potential VI outage
Most scalable, cause performance are limited only by server hardware

Cons

A dedicated physical server is required (it's not recommended mix it with VCB or other services)
Backup must be done using tradition tools
Difficult to manage a disaster recovery solution
Not easy solutions for Business Continuity

Virtual solution: pro and cons

Pro

vCenter Server is just an "appliance", you do not need a dedicated physical server
Faster to restore, you can use VMware HA to restart vCenter Server
Each backup solution that work for a VM work also in this case
Simple solutions for Business Continuity
If you have VMotion license you can move the VM to one ESX to another

Cons

If you do not have VMotion license than you have to power-off vCenter Server to move between ESX (see VMotion section of How work without vCenter Server )
It is susceptible to a potential VI outage
It must contend for resources along with other VMs
In VI 3.x, if license server is on vCenter Server, you can have some big problems after 14 days of downtime (see http://www.riccardoriva.com/archives/703)

P2V or V2P

The P2V conversion is very simple and can be managed by VMware Converter without problem.
The V2P conversion could be a little complicated. See: Moving Virtual Center from VM back to Physical
To move the SQL Server database see this KB:
http://kb.vmware.com/kb/7960893 - VMware Self-Service- Moving the VirtualCenter SQL Database

Reference

http://www.dailyhypervisor.com/?p=1054
Vcenter server physical or virtual
vCenter on a VM v/s vCenter directly on hardware?
Increase the availability of vCenter Server

Increase the availability of vCenter Server

Sun, 01 Nov 2009 07:33:30 GMT

Introduction

There are at least 3 solutions to have HA for vCenter Server:

use a VM for VC and use VMware HA
use vCenter Server Heartbeat product
use a MSCS solution for VC

VMware HA

http://www.vmware.com/products/high-availability/

Only usable when vCenter Server is a VM!
VMware HA require vCenter Server only for the initial setup and configuration.
Than it can work on ESX in a distributed mode, and vCenter Server is not needed to ensure the correct work of HA.
For this reason VMware HA can handle also vCenter Server restart (in this case the downtime could be some minutes...)

IMHO, for small/medium environment I prefer the VMware HA solution... very simple and cheap.
Be sure to have also the vCenter DB on your VM, or you have to find a HA solution also for your DB.

vCenter Server Heartbeat

http://www.vmware.com/products/vcenter-server-heartbeat/

In this case vCenter Server (the primary instance) could be a VM or a physical system. The secondary must be a VM!
Optimize availability and resiliency for VMware vCenter Server in any situation. VMware vCenter Server Heartbeat delivers the maximum uptime for your virtual datacenter infrastructure, ensuring consistent operation, even when VMware vCenter Server is threatened by unplanned or planned downtime.

MSCS or Failover Cluster

http://www.vmware.com/pdf/VC_MSCS.pdf
http://viops.vmware.com/home/docs/DOC-1111 - Reference Implementation: Clustering VirtualCenter 2.5 Using Microsoft Cluster Services

In this case vCenter Server (both the primary and the secondary node) could be a VM or a physical system!
You also need at least Windows Server 2003 (or 2008) Enterprise Edition.
Note that vCenter Server 2.5 is not supported on Windows Server 2008!

Similar to this solution is the usage of other cluster solutions, for example Veritas Cluster:
http://searchservervirtualization.techtarget.com/news/article/0,289142,sid94_gci1341780,00.html

Why not VMware FT?

Is it a good choice-using FT for virtual vCenter server redundancy?
Not yet... vCenter Server 4.0 require 2 vCPU (expecially if you have also a local DB).
FT 1.0 can work only with VM single vCPU.
For more information on FT see: VMware FT

vSphere Host Profiles Deep Dive

Fri, 02 Oct 2009 07:20:14 GMT

Few different new vSphere features have been exhaustively discussed since it was launched back in May’09. I have seen a number of discussions and papers about Fault Tolerance, Storage Thin Provisioning and vDistributed Switches however not much has been said about Host Profiles.

Host Profiles greatly simplify host configuration management in scale-out deployments through user-defined configuration policies. You can use profile policies to eliminate per-host manual host configuration and efficiently maintain configuration consistency and correctness across the entire datacenter(*).

A Host Profile policies can capture the blueprint of a known, validated "golden" configuration and use this to configure networking, storage settings, security settings, and so on for multiple hosts. Host profile policies also monitor compliance to standard host configuration settings across the datacenter.

Using Host Profiles
Profile configurations can be managed via GUI (viClient), vSphere APIs or PowerCLI. Some software and hardware vendors already started to integrate their products with Host Profiles to enhance functionalities such as periodic scans to uncover inconsistencies and provide reporting for Change Management (ITIL) compliance.

Some material have already been published so I won’t recreate. I’m listing some good links and references.

VMware vSphere 4 - Host Profiles Feature from Xtravirt (Paul Davey)
Host Profiles Official VMware Demo
vSphere Host Profiles by Jason Nash (video)
Managing host profiles with vSpherePowerCLI! by Yavor Boychev (video)
Backup/Restore a Host Profile by Graig from the Malaysian VMware Community

Licensing
To be able to use Host Profiles your vSphere environment must be licensed with Enterprise Plus package that also allows you to use vNetwork Distributed Switch, and Third Party Multipathing. It is clear to me based on this post from Eric Siebert that Host Profiles is not one of the hottest features on VMware’s plate however administrators are considering upgrading their licenses to Enterprise Plus. I believe Host Profiles will be soon on the hots when all the hype about other features is over.

This post from Maish Saidel-Keesing explains licensing and pricing in detail.

Limitations
*(*)*Host Profiles will not work work properly in a cluster containing ESX and ESXi hosts due to core differences, such as Service Console and Port Networks. The recommendation is that you create different clusters for each type of hosts and maintain a separate host profiles. This drawback by itself could represent a big challenge in Host Profiles adoption however VMware has already stated that only ESXi will be supported and gain new features in the future.

Other limitations:

Only a single profile can be applied per cluster
Logging on the host

is to the file “pyVmomiserver.log”

Host must be in maintenance mode before a profile can be applied.

Things not covered by Host Profiles are:

Licensing
vDS policy configuration (you can do non-policy vDS)
iSCSI
Multipathing

Some information provided by Forbes Guthrie post.

My Personal Experience using Host Profiles
(Could Host Profiles be more intelligent?) I came across an interesting situation that I rather prefer to think it is a bug to be fixed than a natural behavior. In my production environment I created a Host Profile based on a ESX host (A) and the only difference to ESX host (B) was the NIC Teaming order.

When I applied the profile onto ESX host (B) vCenter informed that the only vSwitch and all port groups in use would be deleted and recreated, including the Service Console and vKernel.

I initially thought it is not possible so I manually changed the NIC Teaming order on ESX host (B) and when I requested to Check Compliance on host ESX (B) it was compliant.

In Summary a simple NIC teaming order change will cause Host Profiles to delete ESX vSwitch and all port groups efore creating it again with the correct configuration.

Few other administrators have been trough the same issue and the simply additional NIC to a vswitch would result in deleting vswitch in recreating vswitch0. However this ends with a communication error between vCenter and the ESX host because the management network is not available anymore (due to deleting vswitch0).

Final Considerations
I have found in many circumstances that use of Host Profiles will co-exist with unattended installations (scripted) helping administrators to achieve consistency over and further than datacenter
boundaries with minimal effort.

Not really related to Host Profiles but would be nice to see vApps understanding host configuration and deciding if that specific configuration or Host Profile applied to the host is adequate for grouped VMs to run.

Host Profiles is a powerful tool to maintain consistency amongst a large number of ESX hosts and will certainly benefit organizations who can afford the salty price of the Enterprise Plus package.

Other useful resources
Meet the Engineer Series: VMware Host Profiles

Andre Leibovici
http://virtualcloud.wordpress.com/

This document was generated from the following thread: vSphere Host Profiles Deep Dive

Availability GUIDE

Tue, 01 Sep 2009 13:25:12 GMT

service VMWARE VirtualCernter Server is down

Tue, 18 Aug 2009 14:28:10 GMT

We have Virtual Center Server Version 2.5.0 built 119598 , and We have a problem constantly the service vmware virtualcenter server is down .

Linked Mode Best Practices

Thu, 04 Jun 2009 22:41:56 GMT

A document on Linked Mode Best Practices is available at the VMware Infrastructure Operations (VIops) portal.

Here is the link to the document: http://viops.vmware.com/home/docs/DOC-1521

Meet the Engineer Series: VMware vCenter Server Linked Mode

Thu, 21 May 2009 23:45:28 GMT

Real people, real faces, discussing VMware vSphere topics...

In this video, two VMware Engineers will discuss VMware vCenter Server Linked Mode which is new with VMware vSphere 4:

{youtube}http://www.youtube.com/watch?v=8En1pl7Bz-c{youtube}

For more "Meet the Engineer" videos, visit the VMware vSphere community Documents tab.

Capacity

Tue, 24 Feb 2009 20:19:53 GMT

Incompatible HA Networks

Tue, 10 Feb 2009 09:35:46 GMT

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006541

Installation of VMware tools into a OpenFiler Guest

Tue, 13 Jan 2009 04:15:55 GMT

To all:

This is my success story with installation of the VMware Tools onto a a OpenFiler NAS. Here is the config that I worked with:

ESX: 3i Build 3.5.0 130775

OpenFiler 2.3 x64 version

Now this might be a little simple for your Linux Admins, but it should be a step by step process for all others out there.

I am assuming that the OpenFiler is installed and running.

Go to the console and log on as root
Update the kernel to the latest version (Not sure if this is necessary, but did it anyway)
1. conary update kernel=openfiler.rpath.org@ofns:2
2. REF:https://forums.openfiler.com/viewtopic.php?id=2789
Reboot the system, then log on again as root
Update all of the packages on the system with the following command:
1. conary updateall
Install a C complier for this distro with the following command:
1. conary update rmake=conary.rpath.com@rpl:1
2. the path of rmake will be /usr/bin/rmake (remember that for later when you install the tools)
3. REF: http://wiki.rpath.com/wiki/rMake:Install_and_Configure
Go to mount directory /mnt. and create a new directory called cd (mkdir cd)
Start the VMware Installation tools from the VI client
Mount the VMware tools with the following command:
1. mkdir /dev/cd
2. mount /dev/cdrom /mnt/cd
Go to your mounted cdrom, copy the tar file and then extract it. The build number of the VMware tools is specific to your version installed
1. cd /mnt/cd
2. cp VMwareTools-3.5.0-130755.tar.gz /tmp
3. cd /tmp
4. tar xvf VMwareTools-3.5.0-130755.tar.gz
5. cd vmware-tools-distrib
6. ./vmware-install.pl
This will start the intallation process, and it should all go well, choose the default locations for all of the requests.
When the questions come up for a compiler like gcc or a c complier for the components like vxnet and the other stuff, it will fail. When the scripts ask you if you would like to choose a specific location, enter Yes
Enter the path of /usr/bin/rmake
Re-enter path of rmake if needed for the rest of script.
It should finish and then volia! the tools are installed.
Check your VI client, it should show OK on the tools
Reboot, and you should be fine

Shawn

Return wandering VMs to their preferred ESX host

Sun, 21 Dec 2008 06:55:50 GMT

There are some cases where its desirable to have a VM running on a specific host in an ESX cluster. This may be operational (grouping VMs with similar service levels together), performance ("manual" load balancing, keeping "developer" VMs seperate from "production" VMs, etc.) or a number of other organizational specific reasons. Over time VMs may "drift" to other hosts due to vMotion moves for patching without the corresponding "move back", failure recovery performed by HA, or administrative reconfiguration. It would be useful to have a way to periodically move any misplaced VMs back to their preferred host. Out-of-the-box there is no capability in ESX or vCenter to provide this "return home" functionality.

Fortunately vCenter Server and the VI Toolkit for Windows provide the necessary infrastructure to implement a short script to perform the necessary moves.

vCenter Server allows additional custom fields to be added to a VM. These custom attributes are available via scripting as well as exposed in the VI Client UI under the "Annotations" field
VI Toolkit for Windows provides the necessary cmdlets to get/set the custom attributes as well as invoke vMotion to move VMs back to their preferred server

There are two scripts in the solution

UpdateTargetHost.ps1 - This script will walk through a set of VMs (either all VMs in a Data Center or the VMs in a specific folder) and set the "VM Target Host" custom attribute to the host where the VM is currently running.
MoveVMtoTargetHost.ps1 - This script will walk through a set of VMs (either all VMs or only those in a specific folder) and, if needed, move the VM back to the host specified in the "VM Target Host" custom field.

The UpdateTargetHost.ps1 script isn't strictly necessary; you could use the VI Client to create the "VM Target Host" custom field and then populate the field in each of your VMs. While that is ok for a few VMs it can be pretty time consuming and error prone as the number of VMs grows. The script provides a quick way of setting the VM's custom field to whatever host the VM is located on when the script is run. So typically you would move your VMs around until they are on the desired hosts, then run the UpdateTargetHost.ps1 script to record the host for each VM. In the future if the desired host placement changed, you could either manually update the custom field entry, or simply move the VMs to the desired hosts and re-run the script.

The MoveVMToTargetHost.ps1 script is meant to be run regularly to move any VMs that are not on their "target" host back to that host. It only operates on VMs that are powered on, and utilizes vMotion to perform the moves (so shared storage is required).

In each of the scripts there is a small customization section that allows you to update some site specific parameters. You'll need to edit these before using the scripts

Update the "connect-viserver InsertYourServerNameHere" to match the name of your vCenter server. So for example if your vCenter server is called "vc01.company.com" then the command would be "connect-viserver vc01.company.com"
The $LOC = Get-Folder "vm" line controls the scope of the changes. Leaving it set to "vm" will run the script against all VMs in vCenter, or you can change "vm" to be any folder name that exists in vCenter, in which case only VMs in that folder will be impacted. The script will not "walk" through mulitple levels of folders however, so if you have a nested folder hierarchy you'll need to create a copy of the script for each folder, or do some script modification to have it walk through nested folders
The $Verbose line controls whether status messages are sent to the console as the script runs. Its handy to leave at $True as you're testing the script and verifying that its working as you intended

You can run the scripts from within PowerShell, or from the command line. If you're running the script from the command line you'll need to include the VI Toolkit for Windows components as well when you invoke PowerShell. The command line below will run the MoveVMToTargetHost script stored in the C:\VCScripts directory

C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe -PSConsoleFile "C:\Program Files\VMware\Infrastructure\VIToolkitForWindows\vim.psc1" -Command C:\VCScripts\MoveVMToTargetHost.ps1

The functionality of the scripts is basic, there isn't a lot of error checking or "fancy stuff" being done. Buyer beward, YMMV, and above all test before using them!

A final word of caution is to think carefully of the consequences of using the script in conjunction with DRS, particularly if you schedule the script to run periodically. If DRS is in "Fully Automated" mode there is a chance (likely a very good one!) that it will "fight" with the scripts to move VMs around (i.e. DRS will move the VMs to balance load, which will cause some of the VMs to be on hosts other than their "target host", at which point the script will move them back, only to have DRS move them again, etc., etc., etc.). This VM movement "thrashing" will cause significant performance issues. But then again, if you're running DRS in "Fully Automated" mode you don't care what hosts your VMs run on, so you won't be using this script anyway

Hopefully you'll find them useful, or at least a useful starting point for your own better-quicker-faster versions.

What update of Virtual Center?

Tue, 25 Nov 2008 14:00:16 GMT

We have build 64192 of the VMware Infrastructure Client and build 84767 VMware VirtualCenter. I also found that we are on version 2.5.0.64207 of the Virtual Infrastructure Client. How can I tell what update I'm running? Thanks - Jim Maloney

84767 is VC 2.5.0 U1

Below you can find all the build information

http://www.vmware.com/download/vi/

if you found this or any other post "helpful" or "correct" please consider awarding points.

This document was generated from the following thread: What update of Virtual Center?

Template customization password setting not working

Wed, 05 Nov 2008 23:20:33 GMT

I have built a new XP machine. I templated it. Now I am trying to deploy from template using the customization wizard. However the password is not getting passed through to the machine. The sysprep is running on the machine and when the machine comes up to the login it will not accept any password. I'm not sure what is happening and I have tried every combination possible. I am not recieving any errors btw.

ESX 3.5.0/VC 2.5.0

I had a very similar issue in the past, for me the answer was a blank password. I don't know how that happened, and someone else took over this project for me and corrected the issue. But the answer at the time was a blank password, have you tried that?

Hope this helps.

While deploying from a template and using the customization wizard to change the PASSWORD there is a caveat that one has to know. I am pasting the below from the VMware Basic system administration guide

" *NOTE You can only change the administrator password if the administrator password on the source Windows virtual machine is blank. If you specify a new administrator password and the source Windows virtual machine or template already has one, the old administrator password does not change"

MemorySizeNotRecommended

Wed, 05 Nov 2008 17:41:47 GMT

Changing from Guest Operating System (in Options) from Windows Standard Edition (64-bit) to Enterprise Edition (64-bit) got rid of the error message. Because of the maximum supported memory by the OS maximum 4GB

Copying vm template to a different SAN - how to make it show up in VIC Template View?

Fri, 24 Oct 2008 22:07:33 GMT

Hi,

I have 2 VMware clusters, each attached to its own SAN, separate by a WAN link. All clusters, hosts and LUNs are visible in the VIC. Using Veeam FastSCP I was able to copy a template folder from one SAN to the other SAN. Using the VIC with Datastores View, I can Browse Datastore and see it. However, how do I make it display in the Hosts and Clusters or Virtual Machines and Templates view in the VIC? Right now I don't know how to access it or use it on the destination SAN, even though it is present.

Thank you for your kind help!

Mak

right click on the .vmtx file and add to inventory and follow the prompts.

Message was edited by: Troy Clavell
corrected file extension name

Hello,

Do you get an add to inventory when you right mouse click the template.vtmx file?

http://blog.laspina.ca/

That is the piece I was missing! Thanks bunches!!! Points awarded.

This document was generated from the following thread: Copying vm template to a different SAN - how to make it show up in VIC Template View?

enter in maitenance mode pb !

Tue, 09 Sep 2008 20:14:16 GMT

Hello,

We have two ESX (v3.5U2) under one cluster (DRS/HA) and in our VC (2.5U2) we try to pass one ESX in maintenance mode without succes.

We look the task blocked to 2% and we have one message per VM's => unable to automatically migrate...

We have no CPU affinity and no other error messages. VMotion and DRS/HA works perfectly except this pb.

Any idea for this issue ?

Thanks for your Help.

Accessing ESX behind firewall

Mon, 25 Aug 2008 19:23:12 GMT

Hi, I have an ESXi server behind a firewall and would like to manage it using the Infrastructure client. What ports should I open up? I have tried opening 902 but am getting a "connection failed" message when trying to access it.

Thanks
Dilan

Failed to install the VirtualCenter Agent Service ??

chris@amssys.lu — Fri, 04 Jul 2008 08:20:32 GMT

I have a VC with 2 ESX

i was able to manage them without problem

since we change our active directory i have lost the connection with one ESX

i can log on directly to it but not through VirtualCenter ESX Disconnected

when i try to reconnect event said Failed to install the VirtualCenter Agent Service

Update Manager had a failure

Tue, 01 Jul 2008 13:41:17 GMT

Task: Scan

Error during the configuration of the host: option -p not recognised.....

VirtualCenter 2.5.0 - 84767

Update Manager 1.0

ESX 3.5.0 98103

ESX 3.5.0 82663 - clean installed 2 days ago

I recently installed update manager and managed to scan and remediate one host, taking it from 82663 to 98103. Now when I scan any of my two hosts I get the above message. Grateful for any help...

Service Console best settings What happens if default gateway fails in HA?

Wed, 18 Jun 2008 00:15:22 GMT

I'm just curious about HW and how it works.

At the moment, I have 3 ESX 3.5 hosts and VC 2.5. Initially, the persons setting them up, out both Service Console and VM's on the same vswitch and on the same internal VLAN. I have now created more VLAN's, which are routed on our firewall (Checkpoint). HA was enabled and was working, but I disabled it when I was setting up new networks and assigning new IP adresses to the SC.

My question is now: what happens if our firewall (router) fails? I know that HA pings the default gateway, but doesn't it detect that the other ESX hosts are still running and does not force a restart of the VM's? I have setup switch redunacy and all virtual switches have dual or triple physical NIC's.

The gateway is only pinged to check if the host is isolated (= has no network connectivity), but this starts only when it stops receiving heartbeats from the other hosts in the cluster. As you have your service consoles probably on the same subnet, they would talk even with a dead GW.

Thanks for the help.

Yes, all my hosts are on the same subnet, so then I know I can survive a downed firewall.

It has a 15 seconds heartbeat and if it found to be isolated than it restart the VMs on other ESX hosts within your cluster. HA heavily depends on your DNS infrastructure and I would place entries in /etc/hosts file for all ESX hosts to make sure if your DNS failed it still communicate via host entries.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

Regards,

Stefan Nguyen
iGeek Systems Inc.
VMware, Citrix, Microsoft Consultant

Best Practice for HA requires redundancy for the Service Console network, this can be accomplished one of two ways:

1. Single Service Console Network with redundant pNICs connected to different pSwitches

2. Secondary Service Console Network. You can create a second SC portgroup on a new or existing vSwitch, and then configure a second Isolation Address (under HA Advanced Options set: das.isolationaddress2 = SecondIPAddress )

Personally I like Option 1 better. Another advanced option you might want to consider setting is changing the default timeout value: das.failuredetectiontime = timeinms

I had changed this from the default of 15 sec to 60000 (60 seconds). This just gives you a little more time before HA thinks you have an isolated/down ESX server.

The other option is to change the default for Isolation Response from Power Off to Leave Powered On. This will make sure VMs do not get powered off for false HA Isolation events. This does mean if the server really is "isolated" the VMs wont be moved, but they should still be up and running, because we are not talking about an ESX server being down, just isolated from the rest of the cluster. IMO its better to leave the VMs running if they are still up and resolve this problem after business hours.

Don Pomeroy
VMware Communities User Moderator

" I would place entries in /etc/hosts file for all ESX hosts to make sure if your DNS failed it still communicate via host entries."

I have a question about this. From what I read in the HA Best Practices doc (http://kb.vmware.com/Platform/Publishing/attachments/1002080_fHA_Tech_Best_Practices.pdf), the ESX server does this automatically and VMware recommends against manually editing the hosts file.

Here is the text from the doc:

1. Proper DNS & Network settings are needed for initial configuration
After configuration DNS resolutions are cached to /etc/FT_Hosts (minimizing the
dependency on DNS server availability during an actual failover)
DNS on each host is preferred (manual editing of /etc/hosts is error prone)

So what is everyone else doing?

This document was generated from the following thread: What happens if default gateway fails in HA?

VMware Infrastructure Client 2.5 update 1 crashes regularly. Any Fixes UPDATE MANAGER

Wed, 11 Jun 2008 02:40:42 GMT

This week I upgraded my Virtual Center server to 2.5.0 BUILD 84767 (Update 1, right?). It appears that Update Manager was not updated in this release.

Anyway, I updated my vpxclient to the same version 2.5.0 BUILD 84767. It has been crashing very often now. Sometimes I get the message "The process cannot access file 'C:\Documents and Settings\myprof\Local Settings\Application Data\VMware\vpx\viclient-X.log' because it is being used by another process." Never had that message until now.

Also, the client will just shut down with a dialog box that I haven't seen before, wanting to send information to Microsoft. No, it's not the standard one for app crashes I'm familiar with. Never seen this particular dialog box until yesterday.

I've had this problem on multiple Windows XP SP2 boxes, where we were running the vpxclient 2.5 just fine. Any advice?

(Also, Update Manager is acting really squirrelly now.)

TIA,

Howard H

Here is a link to a thread where someone was having the same problem. Their solution was to uninstall all the VI-Client pieces and delete all folders pertaining to the VI-Client. Anways check out the link and the solution is the last post. I hope it helps.

http://communities.vmware.com/message/914869#914869

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points

Hi,

I suspect this is a .net code mismatch, the VI client should have the current .net 2.0 installed. Have you tried updating .net?

I had this issue when I installed the update manager client from the plugin manager. In order to fix in my environment, I uninstalled the update manager client code from the machine, and then manually ran the update manager client install from the vc client media from the /vci directory on the root of that cd. That fixed my client and it hasn't crashed since.

-KjB

I've seen this on the forum somewhere indicated you have to remove and replace the .dll files that would resolve your crashes issue. Please search more details since I didn't bookmark that thread sorry

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

Regards,

Stefan Nguyen
iGeek Systems Inc.
VMware, Citrix, Microsoft Consultant

I had removed and reinstalled VI Client already, clearing out directories under Program Files\VMware, to no avail. I reinstalled again this morning, but did not even attempt to install Install manager. I've had no crashes all day. Guess I'll wait for an update on it before installing.

I guess such postings as "Update Manager Sux" have some validity.

I had issues only when I used the plugin manager to install update manager. When I installed the update manager from the vc cd, under the vci folder, vmware-umclient.exe. I have not had any issues after that, and it has been working well ever since.

-KjB

Yes, me too, so far. If installed from the CD (or equivalent) and not downloaded from the VC as a plug-in, even Update Mgr works.

Thanks for your help, kjb007.

This document was generated from the following thread: VMware Infrastructure Client 2.5 update 1 crashes regularly. Any Fixes??

How to update Licensing in VI3

Tue, 08 Apr 2008 16:05:27 GMT

To successfully change a License File for VMware

Log into the Virtual Center Console and make note of the current licenses.
Log out of Virtual center
Download the file from VMWare site
Put the file in the directory structure for the License Server
example C:\program files\vmware\vmware license server\licenses\<file_name.lic>
Open the License Manger
Programs > VMWare > VMWare License Server > VMware License SErver Tools
Select the "Config Services" Tab at the top right
Click "Browse" on the "Path to the License file" option
Point to the file that you downloaded from the VMware site
Click on the "Save Service" button within the same window
Select the "Start/Stop/Reread" tab at the top
Click on "Stop Server"
Click on "Start Server"
Click on "Reread License File"
Wait until you see the message at the bottom of the window
“Reread server License File Completed”
Open the Server Services from within the Administrator Tools.
Restart the "VMWare License Server" service
Restart the "VMWare Virtual Center Server" service
Log into Virtual Center
Click on Admin > and select the Licensing tab at the top.
Right click in the white space below the license columns and select refresh
You should now see New the licenses.

S/w ISCSI and mulitple Targets

Sat, 15 Mar 2008 14:50:04 GMT

Delete Document

High CPU usage after upgrading VirtualCenter 2.x with MSDE database to VirtualCenter 2.5 with MS SQL Server (Express, Standard, Enterprise)

Mon, 03 Mar 2008 04:44:59 GMT

PROBLEM
After upgrading from Virtual Center 2.x with a MSDE Database to Virtual Center 2.5 with a MS SQL Server (Express, Standard or Enterprise) your database server has increasingly lengthy periods of very high CPU utilisation and may become unresponsive.

CAUSE
The SQL upgrade scripts (cleanup_upgrade_mssql.sql) did not complete successfully at the time of the upgrade and were not reported as an error; the upgrade appeared to complete successfully. The stored procedures designed to rollup statistics do not complete their function and eventually consume 100% of resources and never complete.

By default the stats_rollup1_proc process runs every 30 minutes in sqlservr.exe to rollup statistics stored in the table VPX_Hist_Stat1, this process does not complete its function due to the mis-configuration performed by the upgrade and the number of rows in VPX_Hist_Stat1 will continue to grow causing the procedure to overwhelm resources.

WORKAROUND
Use Virtual Infrastructure Client to disable Statistics Collection.
Drop down menu - Administration > VirtualServer Management Server Configuration...
Select - Statistics : Uncheck all collection options

Server CPU usage will revert to normal.

RESOLUTION
Courtesy of Ramprasad K S of VMware Technical Support (KSRam)
I have been able to finish the analysis and reach the root cause. This has
resulted in a possible corrective action without much disruption to existing
installation. The down side of this action is that you will loose any
performance data that is currently stored in the DB.

The root cause here is that the upgrade process failed to completely upgrade.
Though the Wizard shows the process as success, there are some activities
that are not committed correctly.

Corrective action.

Truncate the data from table VPX_HIST_STAT1
Execute each of the commands from C:\Program
Files\VMware\Infrastructure\VirtualCenter
Server\dbupgrade\Upgrade-v3-to-v4\T-SQL\cleanup_upgrade_mssql.sql.

To simplify the process please see the (below process) which would help you
to execute the commands.

These commands (SQL) are to be executed on the VirtualCenter Database.

This action would put the database in correct state so that any further
performance statistics collection is not bothered.

Note: Depending on your configuration you may need to download and install the Microsoft SQL Server 2005 Express Edition Toolkit in order to access the Microsoft SQL Server Management Studio to perform the following process.

1. Shut down the VirtualCenter Server Service

2. Backup the database

3. Execute

TRUNCATE TABLE VPX_HIST_STAT1

4. Execute

TRUNCATE TABLE VPX_HIST_STAT;
alter table vpx_hist_stat drop constraint FK_VPX_HIST_STAT_REF_VPX_SAMP;
truncate table vpx_sample;
CREATE UNIQUE CLUSTERED INDEX PK_VPX_HIST_STAT1 ON VPX_HIST_STAT1
(COUNTER_ID,TIME_ID);
CREATE UNIQUE CLUSTERED INDEX PK_VPX_HIST_STAT2 ON VPX_HIST_STAT2
(COUNTER_ID,TIME_ID);
CREATE UNIQUE CLUSTERED INDEX PK_VPX_HIST_STAT3 ON VPX_HIST_STAT3
(COUNTER_ID,TIME_ID);
CREATE UNIQUE CLUSTERED INDEX PK_VPX_HIST_STAT4 ON VPX_HIST_STAT4
(COUNTER_ID,TIME_ID);

5. Execute

create view VPXV_HIST_STAT_DAILY as
select st.SAMPLE_TIME, st.SAMPLE_INTERVAL, sd.NAME as STAT_NAME,
sd.GROUP_NAME as STAT_GROUP,
case sd.ROLLUP_TYPE
when 0 then 'average'
when 1 then 'maximum'
when 2 then 'minimum'
when 3 then 'latest'
when 4 then 'summation'
when 5 then 'none'
end as STAT_ROLLUP_TYPE,
si.MOID AS ENTITY,
d.DEVICE_NAME, hs.STAT_VAL as STAT_VALUE
from VPX_SAMPLE_TIME1 st
, VPX_DEVICE d
, VPX_STAT_COUNTER sc
, VPX_STAT_DEF sd
, VPX_HIST_STAT1 hs
, VPX_STAT_ID si
where hs.counter_id=sc.COUNTER_ID
and sc.STAT_ID = sd.ID
and isnull(sc.DEVICE_ID,1)=isnull(d.DEVICE_ID,1)
and hs.TIME_ID = st.TIME_ID
and sc.ENTITY_ID=si.ID;

6. Execute

create view VPXV_HIST_STAT_WEEKLY as
select st.SAMPLE_TIME, st.SAMPLE_INTERVAL, sd.NAME as STAT_NAME,
sd.GROUP_NAME as STAT_GROUP,
case sd.ROLLUP_TYPE
when 0 then 'average'
when 1 then 'maximum'
when 2 then 'minimum'
when 3 then 'latest'
when 4 then 'summation'
when 5 then 'none'
end as STAT_ROLLUP_TYPE,
si.MOID AS ENTITY,
d.DEVICE_NAME, hs.STAT_VAL as STAT_VALUE
from VPX_SAMPLE_TIME2 st
, VPX_DEVICE d
, VPX_STAT_COUNTER sc
, VPX_STAT_DEF sd
, VPX_HIST_STAT2 hs
, VPX_STAT_ID si
where hs.counter_id=sc.COUNTER_ID
and sc.STAT_ID = sd.ID
and isnull(sc.DEVICE_ID,1)=isnull(d.DEVICE_ID,1)
and hs.TIME_ID = st.TIME_ID
and sc.ENTITY_ID=si.ID;

7. Exceute

create view VPXV_HIST_STAT_MONTHLY as
select st.SAMPLE_TIME, st.SAMPLE_INTERVAL, sd.NAME as STAT_NAME,
sd.GROUP_NAME as STAT_GROUP,
case sd.ROLLUP_TYPE
when 0 then 'average'
when 1 then 'maximum'
when 2 then 'minimum'
when 3 then 'latest'
when 4 then 'summation'
when 5 then 'none'
end as STAT_ROLLUP_TYPE,
si.MOID AS ENTITY,
d.DEVICE_NAME, hs.STAT_VAL as STAT_VALUE
from VPX_SAMPLE_TIME3 st
, VPX_DEVICE d
, VPX_STAT_COUNTER sc
, VPX_STAT_DEF sd
, VPX_HIST_STAT3 hs
, VPX_STAT_ID si
where hs.counter_id=sc.COUNTER_ID
and sc.STAT_ID = sd.ID
and isnull(sc.DEVICE_ID,1)=isnull(d.DEVICE_ID,1)
and hs.TIME_ID = st.TIME_ID
and sc.ENTITY_ID=si.ID;

8. Exceute

create view VPXV_HIST_STAT_YEARLY as
select st.SAMPLE_TIME, st.SAMPLE_INTERVAL, sd.NAME as STAT_NAME,
sd.GROUP_NAME as STAT_GROUP,
case sd.ROLLUP_TYPE
when 0 then 'average'
when 1 then 'maximum'
when 2 then 'minimum'
when 3 then 'latest'
when 4 then 'summation'
when 5 then 'none'
end as STAT_ROLLUP_TYPE,
si.MOID AS ENTITY,
d.DEVICE_NAME, hs.STAT_VAL as STAT_VALUE
from VPX_SAMPLE_TIME4 st
, VPX_DEVICE d
, VPX_STAT_COUNTER sc
, VPX_STAT_DEF sd
, VPX_HIST_STAT4 hs
, VPX_STAT_ID si
where hs.counter_id=sc.COUNTER_ID
and sc.STAT_ID = sd.ID
and isnull(sc.DEVICE_ID,1)=isnull(d.DEVICE_ID,1)
and hs.TIME_ID = st.TIME_ID
and sc.ENTITY_ID=si.ID;

9. Exceute

CREATE VIEW VPXV_STAT_COUNTERS as
select sd.ID AS ID
,case sd.ROLLUP_TYPE
when 0 then 'average'
when 1 then 'maximum'
when 2 then 'minimum'
when 3 then 'latest'
when 4 then 'summation'
when 5 then 'none'
end as STAT_ROLLUP
, sd.NAME
, sd.GROUP_NAME
, case sd.TYPE
when 0 then 'absolute'
when 1 then 'delta'
when 2 then 'rare'
end as TYPE
, sd.UNIT
, sd.ASSOCIATE_IDS
, sd.STAT_LEVEL AS STATS_LEVEL
FROM VPX_STAT_DEF sd;

10. Exceute

CREATE VIEW VPXV_STAT_HISTORICAL_INTERVALS as
select sid.INTERVAL_SEQ_NUM as ID
, sid.INTERVAL_DEF_NAME as NAME
, sid.INTERVAL_VAL as SAMPLING_PERIOD
, sid.INTERVAL_LENGTH as LENGTH
, sid.STATS_LEVEL
, case sid.ROLLUP_ENABLED_FLG
when 1 then 'Y'
when 0 then 'N'
end as ENABLED
FROM VPX_STAT_INTERVAL_DEF sid;

11. Exceute

drop table VPX_ALARM_EXPRESSION_bk ;
drop table VPX_ALARM_ACTION_bk ;
drop table VPX_SCHED_SCHEDULER_bk ;
drop table VPX_SCHED_ACTION_bk ;
drop table VPX_ACCESS_bk ;
drop table VPX_COMPUTE_RESOURCE_bk ;
drop table VPX_HOST_bk ;
drop table VPX_DATASTORE_bk ;
drop table VPX_NETWORK_bk ;
drop table VPX_RESOURCE_POOL_bk ;
drop table VPX_DS_ASSIGNMENT_bk ;
drop table VPX_HOST_CPU_bk ;
drop table VPX_HOST_NODE_bk ;
drop table VPX_GUEST_DISK_bk ;
drop table VPX_FIELD_DEF_bk ;
drop table VPX_FIELD_VAL_bk ;
drop table VPX_VM_bk ;
drop table VPX_GUEST_IP_ADDRESS_bk ;
drop table VPX_GUEST_NET_ADAPTER_bk ;
drop table vpx_object_type_bk ;
TRUNCATE TABLE VPX_HIST_STAT;
alter table vpx_sample_time1 drop column row_id;
alter table vpx_sample_time2 drop column row_id;
alter table vpx_sample_time3 drop column row_id;
alter table vpx_sample_time4 drop column row_id;
drop procedure hist_stats_upgrade_proc;

Problems starting Virtual Center service error code 2

Wed, 20 Feb 2008 12:43:22 GMT

I have recently installed the Virtual Center 2.5 and it went like a charm!

Now I have rebooted the physical server and I cannot start the Virtual Center service.

Event Viewer said:
The VMware VirtualCenter Server service terminated with service-specific error 2 (0x2). Event ID: 7024

In the most recent logfile (C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs)
it said: Failed to create http proxy: Resource is already in use: Listen socket: :80

I stopped the IIS service, started the Virtual Center service (without problems) and finally I started the IIS service again!

BR
Marcus

VMotion problem - 'device with remote backing' - Greyed out CD-ROM - no vmotion

Fri, 08 Feb 2008 23:30:27 GMT

When trying to VMotion from one ESX server to another, I receive this error:

Unable to migrate from ESX1 to ESX2: Virtual machine is configured to use a device that prevents migration: Device 'CD/DVD Drive 1' is a connected device with a remote backing.

If i view the virtual machine properties, the CD/DVD drive is showing as 'Connected - client unknown'. All of the CD/DVD properties are greyed out.

I can click the 'Disconnect D:' button on the toolbar with the VI client, but this doesnt have any effect.

Any ideas?!

P.S i even tried removing the CD/DVD device whilst the VM was powered off, powering up the VM, powering it down, and re adding the CD/DVD but this didnt have any effect.

Thanks

You should find what is configured to use the device.
Another way: did you try unistalling the device in the virtual OS?

I have this same issuse on a VM i use for testing VMotion, its been used 100's of times for VMotion..

Removing the CD/DVD didnt help, but removing both the CD/DVD and Floppy did the trick..

I havent looked too deeply into it.. But will do later..

I think that is caused by a vcenter user with the console open to the VM that has the CD connected via Device type "Client Device"

Check the sessions on the server and see if anyone has that vm open.

I added my CD/DVD and floppy back, but still get the issues.. But that a good shout, as that VM has had console connected via VC, although all have been closed and VM rebooted etc..

That's really curious. If you can shutdown the vm for a few minutes, try making a new VM pointing to the existing disk files and see if that will vmotion.

Im quite sure that would work, i'll see if i can get chance to test..

Couldn't work out what was causing this...there weren't any sessions showing.
I removed the VM from virtual center, and then re-registered it. This did the trick - can now VMotion OK.

thanks for the suggestions.

Glad to hear that helped.

Thanks for the points!

I'm still having these problems, but now it's happening on 9 of our VMs - a real pain. Only way I can see to fix is to remove the VMs from virtual centre and reregister them.

Just wondering if anyone else has any ideas?

James

Message was edited by:
jparnell

I've had the same problems on my VMs running linux OS-es.
And NOW I resolve the problems!! Yeah!!

The cause is that my VMs hold "VMware Tools Install" images on their Virtual CD-ROM drives.

Click "Inventry->Virtual Machine->End VMware Tools Install".
It may save you.

I have seen this too. If the VM tools install thinks it is still running the CD drive is mapped to the iso file on the host. You wont be able to VMotion until you disable the tools install.

I had the same problem and found this solution in another post:

When trying to vmotion a virtual machine you may get an error message that says you cannot migrate the vm because the CD is connected to a device that prevents migration. If you try to disconnect that device it may stay connected. If it does, open an SSH connection to the ESX host.

Once connected run the following command: "service mgmt-vmware restart"

This will restart the management interface and should clear the connection to the CD or floppy.

Bill S.

I couldn't select to end my instlal but doing a "repair" fixed my remote backing issue.

Ben

I have tried th uninstall and re-install of both the floppy and the CD-Rom although still no luck. What I did find to work more than once it powering down your VM > ensure either Floppy and or CD-Rom are both disconnected > Migrate to another ESX server > Power VM up > try to VMotion.

I hope this helps

JC

Had another one today, I did a 'mgmt-vmware restart' and it fixed the problem.

This should cure the problem without the need to shutdown the VM...

Select "Install VMware Tools" on the Virtual Machine - this will initiate the VMware Tools Installer Mount.

Select "End VMware Tools Install" - this will unmount the Tools Installer.

A word of warning, the VMware Tools Installer Mount will forcibly disconnect the remote device, so if someone has genuinely mounted a Virtual CRDOM it will be lost.

Hi,

I got a similar message during VMOTION. To resolve the issue, i did the following.

1. Rihgtclick on the Virtual Machine and select 'Edit Settings'
2. Select (Highlight) CD/DVD Drive 1
3. On the right hand side under Device status, uncheck the box 'Connected'
4. Try VMOTION (drag and drop the Virtual machine) and it should work.
5. If required then check the box which was unchecked in step 3 (for the moved VM on the target server).

Hope this helps!

Regards,
Ronald

In this scenario the CD/DVD Device Status shows up as "Connected - client unknown" and all of the properties are greyed out, so you can't Edit the Settings.

I am not absolutely certain what the reason is for this behaviour, but I am able to recreate it...

Connect a CD to a VM, then shutdown & power off; now remove the CD (i.e. set to "Client Device"), then power back on. Now try to VMotion and Hey Presto "Device 'CD/DVD Drive 1' is a connected device with a remote backing" and all options greyed out.

The only certain workaround that I have found for this is to "Install VMware Tools"/"End VMware Tools Install", or even better disconnect the CD before shutting down the VM!

I've recently migrated a load of servers using vmware converter - and I have noticed we recieve the error on every server we migrate. I have got into the habbit of "install vmware tools"/"end vmware tools install"

One more addition. The previously posted solutions did not work for me but i found that my guests CDROM was configured to "Emulate IDE" under the Mode section in properties of the CDROM. I set it back to Passthough IDE and vmotion worked with properly.
DG

Had this problem with one machine this morning.

To fix it, I had to remove the cdrom AND floppy disk -> bootup so windows removed them from dev mgr -> shutdown and re-add them. (For good measure, you may consider deleting the hidden devices.)

FWIW, the cd rom was originally set for "Emulate." Changing it to Passthrough did not work for me. I had to remove both devices.

I went into device manager and disabled the floppy drive and cd-rom. Once I did this I clicked edit settings and the cd-rom was no longer connected and I could migrate.

I simply reinstalled my VMWare Tools and it enabled me to VMotion correctly.

Thanks,

Josh

I had this issue on all my VMs since I had installed VMtools. I did a service mgmt-vmware restart on each ESX host 1 min later connected to unknown with the check box was gone...works like a charm.

This document was generated from the following thread: VMotion problem - 'device with remote backing'

Virtual Machines status not correct vissible

Fri, 28 Sep 2007 20:53:23 GMT

Hello,

We have at the office 3 ESX servers, after upgrading to the new version of VirtualCenter 2.0.2 I can see that only on one of our ESX server nodes the status is correct visuable

see screenshot

http://www.fekanv.be/vmware.jpg

Regards,
Kurt

TRy reinstalling vmware tools

I was having the same problem and a service vmware-vpxa restart brought back all of the status lights for my vms.

I see you beat me to the punch bjmoore !

Our shop too has been experiencing this issue. It started after VC 2.0.1 Patch 2. It happens pretty much anytime after a host is rebooted, or the Virtual Center service is restarted on the VC server.

For us this happens 100% of the time upon a host reboot/VC service restart. Every time we have to restart the vpxa client on the host.

I have an open ticket with support, but they haven't been able to fix this issue.

Is anyone else experiencing this issue?

To compare notes. Our VC server is win2k3 R2 SP2, SQL2005 SP2. Fully patched ESX 3.0.1 hosts. Our VMs are a mix of linux and windows. We are running from an iSCSI SAN.

Message was edited by: joelgb

Yep that did the trick

service vmware-vpxa restart

I hope they fix it in the near future

kurt remember to assign points for helpful/correct answers.

See you on VMTN

Pardon my ignorance but where exactly is this vpxa service - on the ESX host itself or the guest VMs? If on the ESX host how do you go about restarting it?

Many thanks.

Chris

You'd SSH into the console of your ESX server, su - to get root access and then type "service vmware-vpxa" restart. It should show you progress for restarting the service. After a few minutes VC will poll the ESX host again and the status lights should reappear.

Fantastic - that's done the trick. Many thanks.

I'm also getting this problem.
I can get the status back by #service vmware-vpxa restart but then if I restart the virtual center service, i lose all the vm status and have to run service vmware-vpxa restart on each host again. Has everyone who upgraded to 2.0.2 got this problem?

I have the same issue :

VCenter 2.0.2
ESX 3.0.2

Some VM's didn't show the status so I restarted the vmware-vpxa service.
Now all VM's don't show the status.
I've done this 15 minutes ago.

???

I saw a similar problem after I restarted the VC service on the windows server it was hosted on. I might suggest restarting that service, then restarting mgmt-vmware and vmware-vpxa again.

good luck!

Now took a look at the affected server and still the VM*s status is missing.

So I did

service vmware-vpxa stop
service mgmt-vmware restart
service vmware vpxa start

and now the status is back :o) but VMware needs to fix it.
I do not want to connect to each ESX (we have about 50 at the moment)
and issue those commands ... what about a centralized CLI interface in VCenter guys ???

It would be easier with it to implement those workarounds ... :o)))

I've got the same issue. Just upgraded VirtualCenter to 2.0.2

VCenter 2.0.2
ESX 3.0.1

Some VMs had a status, some did not. After restarting the VCenter Service I have no status on any VMs

After restarting mgmt and vpxa I now have status on all of my windows server guests, but not for my Linux Guests.

FYI - If I point my VIClient to my host server instead of my Virtual Center Server, I have a status on all guests (even before stopping and restarting mgmt and vpxa)

Message was edited by:
hazent

I see the status of Winodws & Linux VM's after restarting

mgmt-vmware and vmware-vpxa

Did someone create a SR with VMware ?

I think I will create one today.

I've got a SR open...still working on it though.

I just recreated all of my VM-related alarms and that seemed to clear it up, at least for now...

My guess is that even after recreating all your VM alarms, if you restart the Virtual Center Service your status lights will stop working again. At least that is what happens on our setup.

I had a SR open but after trying many things (recreating alarms, reinstalling the vpxa agents on the ESX hosts, total fresh reinstall of virtual center and database on a VM instead of a physical host), it was closed because our ESX servers are not running on supported hardware. We run IBM x345's(not supported) an equallogic SAN, qlogic 4052c HBAs, and each box has Quad Port Intel Gigabit NICs.

bjmoore: If you don't mind, what hardware are you running and are you on totally supported hardware? How much troubleshooting have you done with this issue?

Looks like you're right. After I restarted the VirtualCenter service the status lights disappeared again. I'm on fully supported hardware. Mostly I've been back and forward with support. It seems like they're still trying to get a handle on a lot of the new 2.0.2 bugs. At least this one's not major.

That's not nice !
We have an ELA Platinum.
I will create a SR next monday because I spend today much time in restarting the agents and I can imagine that restarting the VCenter service would end up in loosing all status information.

Our HW is HP Proliant DL 385 G1 / G2 DL 585 HDS San ...

I am seeing the same thing also running on HP hardware

Thank You everyone!
I'm glad my trials are reproducible on supported hardware. For us at least this problem showed up sometime after a 2.0.1 patch back in early June.

Heres what I have gathered so far:
It seems to me that some of the alarms are not working properly and/or are not correctly refreshing the status lights correctly. If you remove all virtual machine alarms, your status lights will never change and will always be white (by design I believe).

Some of the alarms appear to not be changing the status color initially to green. This idea is confirmed as I have noticed that a status light will change if an alarm is triggered (maybe a CPU alarm changing from white to yellow or red, and then will return back to green). From that time on, that VM's status light appears to be working fine. The alarms not initially changing the status light are: VM CPU, VM Mem, VM Disk, VM Network

I then found that If I added either one of the following two alarms, Virtual Machine State or Virtual Machine Heartbeat, the status lights would initially turn green. The status lights continue to stay green even after restarting the Virtual Center Service, no restart of vmware-vpxa on the hosts is required.

So for right now I have added the Virtual Machine Heartbeat monitor, also thinking that maybe the status lights not working are the Virtual Center service missing some heartbeats. The only oddity I am seeing is that powered-off on virtual machines have a status of green. As it was explained to me, powered-off VMs should not display a status light... I haven't had too much time to work on that issue.

Additionally I tried setting the VM State alarm up (set yellow and red triggers to none) and this alarm also makes all status lights turn green.

I've also noticed after upgrading to VC 2.0.2 the alarm actions are not working. Even after restarting VMware-vpxa and mgmt-vmware. I was able to resolve this by disabling the alarm, then re-enabling it.

I am having the same problem with HP 585 G1 /G2 and Fuijtsu Server RX600 S1 .

I have the same issue
I think its because the VC and the ESX rebuild version is not the same
VC = 2.0.2 50618
ESX's = 3.0.2 52542

I have been opened support ticket to that no resolved yet

The lust time its work for me when the VC and ESX's rebuild was the same
VC = 2.0.0 27704
ESX = 3.0.0 27701

Maybe in 3.1.0...

Current fix from support is to run the service restart options for mgmt and vpxa; this does not work for very long however. You will find that after a day the status begins to disappear from the VMs.

Don't care about the build number.

the version is important (ESX 3.0.2 and VC 2.0.2)

I am also seeing this issue, 2.0.2 with 3.01 and 3.02 mixed.

All VMware certified IBM gear.

I also see this issue.

2.02 and 3.02 on HP DL585.

Is it ok to:
service vmware-vpxa stop
service mgmt-vmware restart
service vmware vpxa start
on a production system?
I read that the vm's could restart if you did a restart on mgmt-vmware on a non patched system?

--
Regards Falk
Sweden

I can also see this issue, certified hardware: 2.02 & 3.02 HP DL385 w/ QL4050

It seems that after the 2.02/3.02 upgrade my alarms don't work anymore. I can get them to turn "green" if I add a heart-beat alarm to the VM, however they don't trigger anymore (turn orange or red) for memory or CPU. Only the HB will produce an alarm.

I may remove every alarm and re-create. That and start a ticket with VMW so they know this is a widespread problem.

I also have this problem, very heavy!!!!

3 ESX 3.0.2 (IBM 3650) (DS4800 SAN)

1 VC 2.0.2

What's the solution?

Lieber Mailserver

Vielen Dank für Ihre e-Mail. Ich bin bis am Freitag, 5.10. ausser Haus. Ihre Nachricht wird nicht weitergeleitet.

In dringenden Fällen wenden Sie sich bitte an die Zentrale: +41 32 344 86 00. Diese wird Sie mit einer zuständigen Ansprechperson verbinden.

Freundliche Grüsse
Markus Blunier

The solution is to edit every alarm, and change the values for warn and alarm to something new and apply. Then edit the alarms and change the values back. Aparently the values get truncated during the upgrade and have to be re-created before they are actually set post upgrade.

All of my alarms are now working after editing.

Thanks Bill!
i'll try tomorrow

Bill,

Editing all of the alarms changing yellow and red values; save; and change back to original values resolved my issues with the alarms as well.

Thanks for the good work,

Todd

RESOLVED Editing alarms many thanks!!!

Ercole77

This document was generated from the following thread: Virtual Machines status not correct vissible