This user hasn't shared any biographical information
After investigations, it was discovered that the vCenter service stopped for no reasonable reason. Revising the VC server’s System Event Log, the next error was logged:
The VMware VirtualCenter Server service terminated with service-specific error 2 (0x2).
Cause: You are trying to start the VC service before SQL Service starts. The VC Service should automatically try to restart on its own after 5 minutes after starting the SQL Service.
Resolution: To avoid this and to ensure when trying to start the VC service that the SQL service will start automatically, follow these steps to configure services’ dependencies:
- Obtain the service name for your SQL Service – in Registry Editor, browse to HKLM\System\CurrentControlSet\Services and look for entries starting with MSSQL. In all likelyhood, yours will be called either MSSQL or MSSQL$SQLEXPRESS (ignore MSSQLServerADHelper).
- Now browse to HKLM\System\CurrentControlSet\Services\vpxd
- Open the REG_MULTI_SZ value called DependOnService
- Add a line called MSSQL$SQLEXPRESS (or whatever value you determined above)
- Ensure that the last line in the value is blank
Posted in Administration on January 5, 2011
hostd is an app that runs in the Service Console that is responsible for managing most of the operations on the ESX machine. It knows about all the VMs that are registered on that host, the luns/vmfs volumes visible by the host, what the VMs are doing, etc. Most all commands or operations come down from VC through it. ie, powering on a VM, VM vMotion, VM creation, etc.
vpxa also runs on the Service Console and talks to VC. I believe it acts as an intermediary between VC and hostd. I think it also does some housekeeping on the ESX host, but not as much as hostd.
Posted in Uncategorized on September 28, 2010
The below error commonly occurs when you try to add or connect an ESX 4.1 host to a vCenter 4
A general system error occurred: internal error: vmodl.fault.HostCommunication
The initial connection will work and the vCenter will start to deploy its agent on the ESX, but afterwards you’ll get this error. In my case the ESX host was trying to connect to an old retired vCenter 4 which was started by mistake.
Right click on the faulty host and hit connect while connected to the vCenter 4.1 through the VMware vSphere Client.
I got that error after upgrading my VMware Cluster from vSphere 4 update 2 to vSphere 4.1. Also, I had to migrate my vCenter 4 update 2 (on 32-bit Windows 2003 with MSSQL 2005 installed locally) to vCenter 4.1 (on 64-bit Windows 2008 R2 with a remote MSSQL 2008 R2 Cluster) as vCenter must be install on 64-bit OS.
Anyways, after the upgrade everything went fine escept for some issues like this error:
This error may occure because you are using a custom SQL server database with a custom Java Database Connectivity (JDBC) SQL port
Here are the steps to fix it:
- On the vCenter Server system, navigate to: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter
- Open the vcdb.properties file.
- Comment out the string usevcdb = true.
- Ensure that the values for url, driver, and dbtype are as follows or add them (after the “usevcdb = true” line) if they don’t exist:
url = jdbc:sqlserver://<hostname>:<port>;integratedSecurity=true
driver = com.microsoft.sqlserver.jdbc.SQLServerDriver
dbtype = mssql
- Restart the VMware VirtualCenter Management WebServices service.
Conversions sometimes fail no matter how careful you are preparing the server. The failure can occur at various stages in the conversion process; these stages are based on the task bar percent and are estimated values.
- Creation of the target virtual machine (VM) (0%-5%)
- Preparing to Clone the Disk (5%-6%)
- Cloning (6%-95%)
- Post-cloning (95%-97%)
- Customization/Reconfiguration (97%-99%)
- Install Tools/Power On (99%-100%)
Converter creates a detailed log file during the conversion process which will contain exact errors pertaining to why the conversion failed. This log file is located on the server you are converting that is running the Converter agent, and is usually named vmware-converter-0.log and is located in the C:\Windows\temp\vmware-temp directory.
When you try to SSH login to your ESX host using root account, it gives you “Access denied” message.
This is normal; ESX SSH login using the root account is disabled by default for security purpose. You can login to the host by using either of the below ways:
- Login directly to the ESX host using VI Client (not to the vCenter Server)
- Click Users & Groups tab
- Right-click on a blank area and click Add
- Enter a username and password as shown in the picture. Confirm your password. Note: Starting in ESX 4.0 the password needs to be at least 8 characters in length.
- Select Grant shell access to this user and click OK.
- Open the SSH client (Putty for example).
- Complete the necessary fields. Ensure Port is set to 22 and Protocol is set to SSH. Press Enter or click Open.
- Log in as the new user you created in step 4.
- Type SU – and press enter (This command switches users to root access and provides the path to the root user commands).
- Enter the root password when prompted, press Enter and you are in.
Now, you know how to SSH login using root account but you will need to use the SSH login account (created on step 4 above). If you need to permanently login using root account directly without the need to use a temp account you will need to edit it the “ssh_config” file to permanently enable root account to login directly.
Here are the steps:
- Open a SSH session and login using steps mention above.
- Type command: nano /etc/ssh/sshd_config
- Find the line the says: PermitRootLogin and change the “no” to “yes” .
- save the file and exit.
- Restart the sshd process by typing /etc/init.d/sshd restart .
Now, you can permanently login to SSH using root account directly.