Purging old data from the database used by vCenter Server 4.x

• If the DB has reached a 4GB limit in SQL express, if the DB is corrupted, or if vCenter is unavailable for any reason, purge the event and event_arg tables either by manually enabling the DB retention policy in the DB using SQL Studio, or by running the stored procedure to purge the data from these tables
• • To enable the database retention policy for the events and tasks, Open table dbo.VPX_PARAMETER:
  • • Modify event.maxAge to a value in days.
    • Modify event.maxAgeEnabled to value of true.
    • Modify task.maxAge to a value in days.
    • Modify task.maxAgeEnabled to a value of true
  • Run the built in stored procedure: from the VCDB > Programmability > Stored Procedures > Right-Click dbo.cleanup_events_tasks_proc and click execute. This will purge the data from tables:vpx_event, vpx_event_arg and vpx_task based on the date specified for maxAge
    
    
    
    
    Fonte : VMware KB

Upgrading to VMware Data Recovery 1.2.1

Fonte : VMware Data Recovery 1.2.1 Release Notes

Download : VMware Data Recovery 1.2.1

Previous Data Recovery installations are likely to have existing restore points that should be preserved. To ensure these restore points are preserved, it is important to use the following processes described in this section.

Begin the upgrade process by installing the latest Data Recovery plug-in for the vSphere client.

To install the latest Data Recovery plug-in

1. Close the vSphere Client.
2. Use the Add or Remove Programs item in the Control Panel to uninstall any previous versions of theVMware Data Recovery plug-in.
3. Start the latest Data Recovery plug-in Windows Installer File (.msi) to install the Data Recovery plug-in.

Next you must deploy the new Data Recovery appliance without deleting existing restore points. If the destination volume for the deduplication store is a virtual disk, do not to delete the appliance. Deleting the appliance deletes the disks connected to the appliance. This would cause the backup data stored in the deduplication store to be deleted. To avoid such an issue, complete the following procedure:

To upgrade Data Recovery appliances with virtual disks or RDMs

1. IMPORTANT: Before upgrading to VMware Data Recovery 1.2.1, make sure all operations in your current environment have completed before shutting down and performing the upgrade. If an integrity check or reclaim operation is running, allow the operation to complete. Do not CANCEL these operations.
2. When no operations are running, unmount the destination disk and shut down the Data Recovery appliance.
3. If you want to save the original Data Recovery appliance, rename it in some way. For example, you might rename an appliance called VMware Data Recovery to VMware Data Recovery - OLD.
4. Deploy the new appliance.
5. Use the datastore browser to move the disk containing the deduplication store to the same location as the new appliance.
6. Edit the settings of the new appliance:
1. Choose a Add > Hard Disk.
2. Choose Use an Existing Virtual Disk
3. Browse to the data store and select the virtual disk which is connected to the older appliance as destination.
4. Choose the SCSI address.
5. Choose Finish.
7. Power on the new appliance.
8. Edit the settings of the older appliance:
1. Choose the hard disk which is used to store deduplication store.
2. Select Remove, leave default option for remove from virtual machine. DO NOT select remove from virtual machine and delete files from the disk.
3. Click OK.
9. Configure networking on the new appliance.
10. Use the Data Recovery vSphere plug-in to connect to the backup appliance.
11. Complete the getting started wizard. Note that you should mount the desired disk, but do not format it. Formatting the disk will erase all deduplication store data. The disk to be used may not display the expected name, but the proper name will be displayed after the wizard is completed.
12. You are prompted to restore the configuration from the deduplication store. Select Yes if you want to restore the jobs and backup events and history.
13. The client disconnects from the appliance after the configuration is restored and then reestablishes the connection. This may take several minutes.
14. Once the client reconnects, check to see if a Reclaim or Integrity check operation has started. If so, STOP the operation.
15. Immediately click Configure > Destinations and perform an integrity check on all mounted destinations.
16. Verify the backup job configuration.
17. Remove the older VMware Data Recovery appliance from the inventory.

Note that damaged restore points may cause the upgrade to fail. If you receive the message "Could not restore the Data Recovery appliance configuration" re-add the destination to the original Data Recovery appliance and then run an integrity check to clean up any damaged restore points. After the integrity check completes successfully, repeat the upgrade process.

Storage iSCSI bloccato e nodi vSphere disconnessi

Si è bloccato uno storage iSCSI (in questo caso un Buffalo) ed i nodi vSphere sono andati in panne? Le vm attive continuavano a funzionare regolarmente ma non è possibile raggiungere con l’infrastructure client i nodi e dal vcenter risultano disconnessi.

Una volta riavviata lo storage iSCSI potrebbe essere necessario rieseguire un rescan dello stesso dagli hypervisor:

Dalla console SSH:

# esxcfg-mpath –l

Si ottiene la lista dei vmhba. Qualcosa del genere:

Device Display Name: IET iSCSI Disk (t10.945445000000000000000000100000000000000020000000030323431453235324633354)

Adapter: vmhba34 Channel: 0 Target: 0 LUN: 0

Adapter Identifier: iqn.1998-01.com.vmware:vSphere01-1f93b11d

Target Identifier:

Plugin: NMP

State: dead

Transport: iscsi

Una volta individuato l’hba morto eseguire il rescan:

# esxcfg-rescan vmhba34

Device Display Name: IET iSCSI Disk (t10.945445000000000000000000100000000000000020000000030323431453235324633364)

Adapter: vmhba34 Channel: 0 Target: 2 LUN: 0

Adapter Identifier: iqn.1998-01.com.vmware:vSphere01-1f93b11d

Target Identifier: 00023d000001,iqn.2004-08.jp.buffalo:iSCSI-CB-02-0024A525B63F:iSCSI-CB02,t,1

Plugin: NMP

State: active

Transport: iscsi

A questo punto dovremmo riuscire a collegarci al singolo nodo con il vic altrimenti potrebbe essere necessario riavviare i servizi di management (Se sono state impostate opzioni di avvio/spegnimento automatico delle vm il riavvio dei servizi di management ne provoca l’arresto)

# service mgmt-vmware restart

# service vmware-vpxa restart

Una volta collegati al vic, se le vm rimangono inaccessibili, avviare un rescan degli hba per rieseguire il mount dei volumi vmfs

A partire da esx 4 update 1 è possibile applicare un workaround che dovrebbe minimizzare l’impatto di un hba morto sull’infratruttura.