A host in OpenNebula represents a hypervisor node that the scheduler can monitor and use for VM placement. Removing a host is common when a compute node is retired, rebuilt, or replaced, but the inventory change should happen only after workloads have left the node.

The front-end shell uses onehost flush and onehost delete for this cleanup. onehost flush disables the target host and asks OpenNebula to reschedule running VMs to other hosts with enough capacity, while onehost delete removes the drained host object from the pool.

Host removal does not uninstall packages from the hypervisor or erase local storage outside the normal OpenNebula VM lifecycle. Confirm VM state, storage compatibility, and scheduler capacity before deleting the host, especially when the node uses local system datastore storage or has VMs pinned by placement requirements.

Steps to drain and delete an OpenNebula host:

  1. List the host pool and identify the host to remove.
    $ onehost list
      ID NAME        CLUSTER     RVM   TCPU   FCPU   ACPU   TMEM   FMEM   AMEM STAT
       0 host01      default       1    800    540    800  31.1G  19.4G  31.1G   on
       1 host02      default       2    800    620    800  31.1G  22.1G  31.1G   on

    RVM shows how many running VMs are assigned to each host. Use the host ID or name in later commands.

  2. Show the target host before moving workloads.
    $ onehost show host02
    HOST 1 INFORMATION
    ID                    : 1
    NAME                  : host02
    CLUSTER               : default
    STATE                 : MONITORED
    IM_MAD                : kvm
    VM_MAD                : kvm
    
    HOST SHARES
    RUNNING VMS           : 2
    ##### snipped #####
    
    VIRTUAL MACHINES
    
      ID USER     GROUP    NAME            STAT UCPU    UMEM HOST     TIME
      18 oneadmin oneadmin db01            runn  0.2      2G host02   2d 04h21
      19 oneadmin oneadmin worker01        runn  0.1      1G host02   1d 07h12

    The VIRTUAL MACHINES block names OpenNebula-managed VMs assigned to the host. Wild VMs reported outside this list need hypervisor-level handling before the node is retired.

  3. Flush the target host.
    $ onehost flush host02
    HOST 1: flushing

    onehost flush disables the host and reschedules running VMs. The migration action can be configured in /etc/one/cli/onehost.yaml, so confirm that policy before using it on a node with local storage or strict downtime requirements.

  4. Check VM placement after the scheduler moves workloads.
    $ onevm list
      ID USER     GROUP    NAME            STAT UCPU    UMEM HOST     TIME
      17 oneadmin oneadmin web01           runn  0.1      1G host01   5d 02h30
      18 oneadmin oneadmin db01            runn  0.2      2G host01   2d 04h24
      19 oneadmin oneadmin worker01        runn  0.1      1G host01   1d 07h15

    If VMs stay on host02 or move to pend, inspect scheduler capacity and placement requirements before deleting the host.
    Related: How to troubleshoot OpenNebula scheduling

  5. Verify that the host is disabled and empty.
    $ onehost show host02
    HOST 1 INFORMATION
    ID                    : 1
    NAME                  : host02
    CLUSTER               : default
    STATE                 : DISABLED
    IM_MAD                : kvm
    VM_MAD                : kvm
    
    HOST SHARES
    RUNNING VMS           : 0
    ##### snipped #####
    
    VIRTUAL MACHINES

    The host should show no VIRTUAL MACHINES entries before deletion.

  6. Delete the drained host from OpenNebula.
    $ onehost delete host02
    HOST 1: deleted

    Do not delete a host while VMs still appear under onehost show. The host object disappears from OpenNebula, but node packages, local files, and hypervisor services remain on the server.

  7. List hosts again and confirm the removed host is absent.
    $ onehost list
      ID NAME        CLUSTER     RVM   TCPU   FCPU   ACPU   TMEM   FMEM   AMEM STAT
       0 host01      default       3    800    480    800  31.1G  17.8G  31.1G   on