Process Sendmail clientmqueue

You have emails stuck in clientmqueue that are stuck because of a prior sendmail issue.

To process all e-mails in the clientmqueue:

 

sendmail -Ac -q -v

Manually flush clientmqueue:
sendmail -Ac -q -v

00:0c:29:4c:6f:70 is not an allowed static Ethernet address. It conflicts with VMware reserved MACs.

You are attempting to manually assign a MAC to a vSphere VM in the 00:0c:29:xxx range.

You receive this error:

Module DevicePowerOn power on failed.
Could not set up “macAddress” for ethernet0.
Invalid MAC address specified.
00:0c:29:4c:6f:70 is not an allowed static Ethernet address. It conflicts with VMware reserved MACs.

Solution:  Edit the .vmx file for the VM and add this line:

ethernet0.checkMACAddress = "false"

vCSA Postgres Database Repair – PANIC: checksum mismatch

You are confronted with various database errors in the /var/log/vmware/vpx/vpxd.log and you also have various errors in /storage/db/vpostgres/pg_log

Similar in theme to:

error ‘Default’ opID=HB-host-8637@82541-3778684f] [VdbStatement] SQLError was thrown: “ODBC error: (00000) – ” is returned when executing SQL statement

error ‘Default’ opID=HB-host-8637@82541-3778684f] An unrecoverable problem has occurred, stopping the VMware VirtualCenter service. Error: Error[VdbODBCError] (-1) “ODBC error: (00000) – ” is returned when executing SQL statement

PANIC: checksum mismatch: disk has 0x4addc132, should be 0x7cb3b932
filename base/16385/24461, BlockNum 37, block specifier 1663/16385/24461/0/37

Cause:

The root cause is you likely lost power, but the larger problem is obviously that the VMware vCSA is built using one of the most un-user friendly databases in this galaxy (Postgres).  With that said, let’s get this hunk of garbage beautiful piece of modern infrastructure management back online.

Solutions:

Repair vPostgres Indexes:

If you have Index errors in the log file (anything mentioning issues with *idx), you will need to regenerate the particular index in the Postgres database.    To accomplish this:

  1. Get your postgres password:  cat /etc/vmware-vpx/embedded_db.cfg | grep PASSWORD
  2. You will need to add a shell to the postgres user:  type:  ‘vipw’, locate the postgres user, change the shell from /bin/false to /bin/bash, save the file (:wq!)       It will look this when you are done:  postgres:x:1000:100::/var/vmware/vpostgres/9.0:/bin/bash
  3. su postgres
  4. /opt/vmware/vpostgres/9.0/bin/psql VCDB
  5. REINDEX DATABASE;
  6. Optional and recommended:  VACUUM FULL; (this will recover disk space and will recreate all of your tables)

Repair vPostgres Data:

If you have errors in your logs that complain about invalid checksums, you will need to force Postgres to fix these.   There is no MySQL type command to automatically repair all databases (glorious!).  You will need repair each issue manually.   There will likely only be one that is preventing vCenter from fully starting.

Your error message will look like this:

PANIC: checksum mismatch: disk has 0x4addc132, should be 0x7cb3b932
filename base/16385/24461, BlockNum 37, block specifier 1663/16385/24461/0/37

filename base/16385/54431780, BlockNum 102, block specifier 1663/16385/54431780/0/102

To fix these errors (there might be more than one):

  1. service vmware-vpxd stop ; service vmware-vpostgres stop
  2. Get your postgres password:  cat /etc/vmware-vpx/embedded_db.cfg | grep PASSWORD
  3. You will need to add a shell to the postgres user:  type:  ‘vipw’, locate the postgres user, change the shell from /bin/false to /bin/bash, save the file (:wq!)
  4. su postgres
  5. /opt/vmware/vpostgres/9.0/bin/postgres -D /storage/db/vpostgres -c fix_block_checksum=”1663/16385/54431780/0/102″   [Note: this last section is just a copy and paste of the “block specifier from the log file”.]

 

Acronis True Image TIB to VMware VM

How to convert an Acronis True Image TIB backup file to a VMware VM.

  1. Create a VM with the same OS as the backup with a larger disk than the backup.  How much bigger does not matter.
  2. Boot the VM with the Acronis True Image recovery ISO.  If you do not have this, it is available for download on various websites and found via a Google search.
  3. Once the ISO is booted, choose recovery and connect to the remote location with the TIB file.  I find a local FTP connection to work fine.
  4. After the restore is done, reboot the VM and see if it is boots.  It likely won’t boot.  Don’t waste any time trying to troubleshoot.
  5. Load up VMware converter and convert the VM.   VMware converter will fix all drive label, boot, etc issues.  You will have a fully functioning VM once it is done.
  6. Host your Acronis True Image TIB at VMDK Hosting.   They will do the entire conversion listed above for you and host the exported VMware VM.