B Removing Orphan and Ghost vServers After Restoring the Exalogic Control Stack

When you restore the Exalogic Control stack from a backup, it reverts to the point in time when that backup was created.

  • vServers that were created after that backup will not be displayed in Exalogic Control (orphan vServers).

  • vServers that were deleted after that backup will be displayed in Exalogic Control, but they do not exist (ghost vServers).

So after restoring the Exalogic Control stack, you must remove such vServers, by performing the following steps:

  1. Log in to Oracle VM Manager as the root user.

  2. Identify the vServer GUID of orphan vServers, by doing the following:

    1. Click the Servers and VMs tab.

    2. Expand Server Pools.

    3. Click a server pool.

    4. From the Perspective drop down box, select Virtual Machines.

    5. Expand a vServer called ORPHAN_GUID.

    6. From the Configuration tab of the vServer, note the vServer GUID (ID) of the vServer.

    7. Repeat steps e and f for all vServers called ORPHAN_GUID.

    8. If you have more than one server pool, repeat steps c to g for each server pool.

  3. Identify the names and vNIC GUIDs of the orphan vServers, by doing the following:

    1. Log in to any running Oracle VM Server node as the root user.

    2. Note the names of orphan vServers, using the GUIDs you identified in step 2, by running the following command:

      grep simple_name /OVS/Repositories/Repository_ID/VirtualMachines/vServer_GUID/vm.cfg
      

      Example:

      grep simple_name /OVS/Repositories/0004fb00000300004147155f08fb017b/VirtualMachines/0004fb00000600008c6cfab8bb065dff/vm.cfg OVM_simple_name = 'vsrvr'
      

      In this example, the vServer with the GUID 0004fb00000600008c6cfab8bb065dff is called vsrvr.

    3. Note the vNIC GUIDs of orphan vServers, using the GUIDs you identified in step 2, by running the following command:

      grep exalogic_vnic /OVS/Repositories/Repository_ID/VirtualMachines/vServer_GUID/vm.cfg
      

      Example:

      grep exalogic_vnic /OVS/Repositories/0004fb00000300004147155f08fb017b/VirtualMachines/0004fb00000600008c6cfab8bb065dff/vm.cfg 
      exalogic_vnic = [{'pkey': ['0x8006'], 'guid': '0xfdc7b8890128889c', 'port':
      '1'}, {'pkey': ['0x8006'], 'guid': '0xfdc7b8890128889d', 'port': '2'}]
      

      In this example, the orphan vServer with the GUID 0004fb00000600008c6cfab8bb065dff has the vNIC GUIDs fdc7b8890128889c and fdc7b8890128889d. Ensure that you note the GUIDs without the 0x prefix.

    4. Repeat step b and c for all vServer GUIDs you noted in step 2.

  4. Refresh the Oracle VM Manager repository, by doing the following:

    1. Click the Repositories tab.

    2. Select the repository.

    3. Click the refresh icon.

      After the repository refresh, orphaned vServers will display their actual names and ghost vServers will display errors.

  5. Identify the vServer GUID (ID) of ghost vServers, by doing the following:

    1. Click the Servers and VMs tab.

    2. Expand Server Pools.

    3. Click a server pool.

    4. From the Perspective drop down box, select Virtual Machines.

    5. Expand the vServer for which the status is stopped and the Event Severity displays an error.

    6. Note the GUID (ID) and name of the ghost vServer.

    7. If you have more than one server pool, repeat steps c to f for each server pool.

  6. Acknowledge the Oracle VM Manager events of vServers that cannot start due to errors, by doing the following:

    1. Click the Servers and VMs tab.

    2. Expand Server Pools.

    3. Click the server pool running the vServer that is in the error state.

    4. From the Perspective drop down box, select Virtual Machines.

    5. Right click on a vServer for which its Event Severity displays an error.

    6. Click Display Events.

    7. Click Acknowledge All.

    8. Repeat steps e to g for all vServers that cannot run due to errors.

    9. Refresh the Server Pools view, by clicking the Repository tab and then the Servers and VMs tab.

    10. Verify that a green status icon is displayed for all Oracle VM Server nodes, once all vServers in the error state have been acknowledged.

  7. Delete all orphan vServers in Oracle VM Manager, by doing the following:

    1. Select an orphan vServer.

      You can identify these vServers by using the names you noted in step 3 and GUIDs you noted in 2.

    2. Click the Stop button.

      The confirmation box appears.

    3. Click OK.

      A job to stop the vServer is created.

    4. Wait for the job to stop the vServer to complete.

    5. Select the vServer you stopped.

    6. Click the Delete button.

      The confirmation box appears.

    7. Under Select virtual disks to delete, select all virtual disks that are displayed.

    8. Click OK.

    9. Repeat steps a to h for all orphan vServers.

  8. Delete vNICs associated with all orphan vServers, by doing the following:

    1. Log in to an InfiniBand Gateway switch as root.

    2. Identify the connector and vNIC ID of the vNIC whose GUID you identified in step 3:

      showvnics | egrep -i "vnic_guid1|vnic_guid2"
      

      Example:

      showvnics | egrep -i "fdc7b8890128889c|fdc7b8890128889d"
      89 WAIT-IOA  N  FDC7B8890128889C alpha05cn04 EL-C 192.168.54.74 0000 00:21:F6:CC:BB:AA 20 8006   0A-ETH-1 
      

      In this example, for the GUID FDC7B8890128889C, the vNIC ID is 89 and the connector is 0A-ETH-1.

      Note:

      If this command does not display any results, run the command on the other gateway switch as described in step d.
    3. Delete the vNIC:

      deletevnic connector vnic_id 
      

      Example:

      deletevnic  0A-ETH-1  89 
       
      
    4. On all other InfiniBand Gateway switches, run steps a to c.

    5. Repeat steps a to d for all the vNICs whose GUIDs you identified in step 3.

  9. Before deleting ghost vServers, you must create vm.cfg files for these vServers by doing the following:

    1. Log in to any running Oracle VM Server node as the root user.

    2. Run the following command to navigate to the VirtualMachines directory of your repository:

      cd /OVS/Repositories/Repository_ID/VirtualMachines/
      

      Repository_ID is the ID of your repository.

    3. Verify that no directory exists for the ghost vServer, by running the ls command with the vServer GUID of a ghost vServer:

      ls vServer_GUID
      

      Example:

      ls 0004fb00000600008c6cfab8bb064dbb
      ls: 0004fb00000600008c6cfab8bb064dbb: No such file or directory
      
    4. Create a directory using the vServer GUID, say 0004fb00000600008c6cfab8bb064dbb, as follows:

      mkdir 0004fb00000600008c6cfab8bb064dbb
      
    5. Create an empty vm.cfg file for the vServer, say with vServer GUID 0004fb00000600008c6cfab8bb064dbb, as follows:

      touch 0004fb00000600008c6cfab8bb064dbb/vm.cfg
      
    6. Repeat steps c to e for all ghost vServers.

    7. Refresh the repository as described in step 4.

      vServers for which you created vm.cfg files should be shown in the error state again.

  10. Delete all ghost vServers that you created vm.cfg files for, by doing the following:

    1. Log in to the Exalogic Control BUI as a user with the Exalogic Systems Administrator role.

    2. From the left navigation pane, click vDC Accounts.

    3. Under vDC Accounts, expand the name of your Account.

    4. Click the ghost vServer you are deleting, using the name you noted in step 5.

      The vServer dashboard appears.

    5. Verify that the domain ID of the vServer matches the vServer GUID you noted in step 5.

    6. From the Actions pane on the right, click the delete button.

      The Delete vServer confirmation screen appears.

    7. Click Delete to confirm.

    8. Repeat steps d to g for all ghost vServers for which you created vm.cfg files.