3.2. Backups and Migration

Procedure

1. Log in to one of the self-hosted engine nodes and move the environment to global maintenance mode:

   # hosted-engine --set-maintenance --mode=global

2. Log in to the original Manager and stop the ovirt-engine service:

   # systemctl stop ovirt-engine
   # systemctl disable ovirt-engine

   Note

   Though stopping the original Manager from running is not obligatory, it is recommended as it ensures no changes are made to the environment after the backup is created. Additionally, it prevents the original Manager and the new Manager from simultaneously managing existing resources.

3. Run the engine-backup command, specifying the name of the backup file to create, and the name of the log file to create to store the backup log:

   # engine-backup --mode=backup --file=file_name --log=log_file_name

4. Copy the files to an external server. In the following example, storage.example.com is the fully qualified domain name of a network storage server that will store the backup until it is needed, and /backup/ is any designated folder or path.

   # scp -p file_name log_file_name storage.example.com:/backup/

5. If you do not require the Manager machine for other purposes, unregister it from Red Hat Subscription Manager:

   # subscription-manager unregister

6. Log in to one of the self-hosted engine nodes and shut down the original Manager virtual machine:

   # hosted-engine --vm-shutdown

Procedure

1. Copy the backup file to the new host. In the following example, host.example.com is the FQDN for the host, and /backup/ is any designated folder or path.

   # scp -p file_name host.example.com:/backup/

2. Log in to the new host.

3. If you are deploying on Red Hat Virtualization Host, ovirt-hosted-engine-setup is already installed, so skip this step. If you are deploying on Red Hat Enterprise Linux, install the ovirt-hosted-engine-setup package:

   # dnf install ovirt-hosted-engine-setup

4. Use the tmux window manager to run the script to avoid losing the session in case of network or terminal disruption.

   Install and run tmux:

   # dnf -y install tmux
   # tmux

5. Run the hosted-engine script, specifying the path to the backup file:

   # hosted-engine --deploy --restore-from-file=backup/file_name

   To escape the script at any time, use CTRL+D to abort deployment.

6. Select Yes to begin the deployment.
7. Configure the network. The script detects possible NICs to use as a management bridge for the environment.
8. If you want to use a custom appliance for the virtual machine installation, enter the path to the OVA archive. Otherwise, leave this field empty to use the RHV-M Appliance.
9. Enter the root password for the Manager.
10. Enter an SSH public key that will allow you to log in to the Manager as the root user, and specify whether to enable SSH access for the root user.
11. Enter the virtual machine’s CPU and memory configuration.
12. Enter a MAC address for the Manager virtual machine, or accept a randomly generated one. If you want to provide the Manager virtual machine with an IP address via DHCP, ensure that you have a valid DHCP reservation for this MAC address. The deployment script will not configure the DHCP server for you.

13. Enter the virtual machine’s networking details. If you specify Static, enter the IP address of the Manager.

    Important

    The static IP address must belong to the same subnet as the host. For example, if the host is in 10.1.1.0/24, the Manager virtual machine’s IP must be in the same subnet range (10.1.1.1-254/24).

14. Specify whether to add entries for the Manager virtual machine and the base host to the virtual machine’s /etc/hosts file. You must ensure that the host names are resolvable.
15. Provide the name and TCP port number of the SMTP server, the email address used to send email notifications, and a comma-separated list of email addresses to receive these notifications:

16. Enter a password for the admin@internal user to access the Administration Portal.

    The script creates the virtual machine. This can take some time if the RHV-M Appliance needs to be installed.

    Note

    If the host becomes non operational, due to a missing required network or a similar problem, the deployment pauses and a message such as the following is displayed:

    [ INFO  ] You can now connect to https://<host name>:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
    [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
    [ INFO  ] ok: [localhost]
    [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file]
    [ INFO  ] changed: [localhost]
    [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]

    Pausing the process allows you to:

    • Connect to the Administration Portal using the provided URL.
    • Assess the situation, find out why the host is non operational, and fix whatever is needed. For example, if this deployment was restored from a backup, and the backup included required networks for the host cluster, configure the networks, attaching the relevant host NICs to these networks.
    • Once everything looks OK, and the host status is Up, remove the lock file presented in the message above. The deployment continues.

17. Select the type of storage to use:

    • For NFS, enter the version, full address and path to the storage, and any mount options.

      Warning

      Do not use the old self-hosted engine storage domain’s mount point for the new storage domain, as you risk losing virtual machine data.

    • For iSCSI, enter the portal details and select a target and LUN from the auto-detected lists. You can only select one iSCSI target during the deployment, but multipathing is supported to connect all portals of the same portal group.

      Note

      To specify more than one iSCSI target, you must enable multipathing before deploying the self-hosted engine. See Red Hat Enterprise Linux DM Multipath for details. There is also a Multipath Helper tool that generates a script to install and configure multipath with different options.

    • For Gluster storage, enter the full address and path to the storage, and any mount options.

      Warning

      Do not use the old self-hosted engine storage domain’s mount point for the new storage domain, as you risk losing virtual machine data.

      Important

      Only replica 1 and replica 3 Gluster storage are supported. Ensure you configure the volume as follows:

      gluster volume set VOLUME_NAME group virt
      gluster volume set VOLUME_NAME performance.strict-o-direct on
      gluster volume set VOLUME_NAME network.remote-dio off
      gluster volume set VOLUME_NAME storage.owner-uid 36
      gluster volume set VOLUME_NAME storage.owner-gid 36
      gluster volume set VOLUME_NAME network.ping-timeout 30

    • For Fibre Channel, select a LUN from the auto-detected list. The host bus adapters must be configured and connected, and the LUN must not contain any existing data. To reuse an existing LUN, see Reusing LUNs in the Administration Guide.

18. Enter the Manager disk size.

    The script continues until the deployment is complete.

19. The deployment process changes the Manager’s SSH keys. To allow client machines to access the new Manager without SSH errors, remove the original Manager’s entry from the .ssh/known_hosts file on any client machines that accessed the original Manager.

Procedure

1. Register your system with the Content Delivery Network, entering your Customer Portal user name and password when prompted:

   # subscription-manager register

   Note

   If you are using an IPv6 network, use an IPv6 transition mechanism to access the Content Delivery Network and subscription manager.

2. Find the Red Hat Virtualization Manager subscription pool and record the pool ID:

   # subscription-manager list --available

3. Use the pool ID to attach the subscription to the system:

   # subscription-manager attach --pool=pool_id

   Note

   To view currently attached subscriptions:

   # subscription-manager list --consumed

   To list all enabled repositories:

   # dnf repolist

4. Configure the repositories:

   # subscription-manager repos \
       --disable='*' \
       --enable=rhel-8-for-x86_64-baseos-eus-rpms \
       --enable=rhel-8-for-x86_64-appstream-eus-rpms \
       --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
       --enable=fast-datapath-for-rhel-8-x86_64-rpms \
       --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms \
       --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms \
       --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

5. Set the RHEL version to 8.6:

   # subscription-manager release --set=8.6

6. Enable the pki-deps module.

   # dnf module -y enable pki-deps

7. Enable version 12 of the postgresql module.

   # dnf module -y enable postgresql:12

8. Enable version 14 of the nodejs module:

   # dnf module -y enable nodejs:14

9. Synchronize installed packages to update them to the latest available versions.

   # dnf distro-sync --nobest

Procedure

1. Click Compute Hosts and select the host.
2. Click Management Maintenance and OK.
3. Click Installation Reinstall. This opens the Install Host window.
4. Click the Hosted Engine tab and select DEPLOY from the drop-down list.
5. Click OK to reinstall the host.

Procedure

1. Click Storage Domains.

2. Move the storage domain to maintenance mode and detach it:

   1. Click the storage domain’s name. This opens the details view.
   2. Click the Data Center tab.
   3. Click Maintenance, then click OK.
   4. Click Detach, then click OK.
3. Click Remove.
4. Optionally select the Format Domain, i.e. Storage Content will be lost! check box to erase the content of the domain.
5. Click OK.

Procedure

1. Copy the backup file to the new host. In the following example, host.example.com is the FQDN for the host, and /backup/ is any designated folder or path.

   # scp -p file_name host.example.com:/backup/

2. Log in to the new host.

3. If you are deploying on Red Hat Virtualization Host, ovirt-hosted-engine-setup is already installed, so skip this step. If you are deploying on Red Hat Enterprise Linux, install the ovirt-hosted-engine-setup package:

   # dnf install ovirt-hosted-engine-setup

4. Use the tmux window manager to run the script to avoid losing the session in case of network or terminal disruption.

   Install and run tmux:

   # dnf -y install tmux
   # tmux

5. Run the hosted-engine script, specifying the path to the backup file:

   # hosted-engine --deploy --restore-from-file=backup/file_name

   To escape the script at any time, use CTRL+D to abort deployment.

6. Select Yes to begin the deployment.
7. Configure the network. The script detects possible NICs to use as a management bridge for the environment.
8. If you want to use a custom appliance for the virtual machine installation, enter the path to the OVA archive. Otherwise, leave this field empty to use the RHV-M Appliance.
9. Enter the root password for the Manager.
10. Enter an SSH public key that will allow you to log in to the Manager as the root user, and specify whether to enable SSH access for the root user.
11. Enter the virtual machine’s CPU and memory configuration.
12. Enter a MAC address for the Manager virtual machine, or accept a randomly generated one. If you want to provide the Manager virtual machine with an IP address via DHCP, ensure that you have a valid DHCP reservation for this MAC address. The deployment script will not configure the DHCP server for you.

13. Enter the virtual machine’s networking details. If you specify Static, enter the IP address of the Manager.

    Important

    The static IP address must belong to the same subnet as the host. For example, if the host is in 10.1.1.0/24, the Manager virtual machine’s IP must be in the same subnet range (10.1.1.1-254/24).

14. Specify whether to add entries for the Manager virtual machine and the base host to the virtual machine’s /etc/hosts file. You must ensure that the host names are resolvable.
15. Provide the name and TCP port number of the SMTP server, the email address used to send email notifications, and a comma-separated list of email addresses to receive these notifications:

16. Enter a password for the admin@internal user to access the Administration Portal.

    The script creates the virtual machine. This can take some time if the RHV-M Appliance needs to be installed.

    Note

    If the host becomes non operational, due to a missing required network or a similar problem, the deployment pauses and a message such as the following is displayed:

    [ INFO  ] You can now connect to https://<host name>:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
    [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
    [ INFO  ] ok: [localhost]
    [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file]
    [ INFO  ] changed: [localhost]
    [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]

    Pausing the process allows you to:

    • Connect to the Administration Portal using the provided URL.
    • Assess the situation, find out why the host is non operational, and fix whatever is needed. For example, if this deployment was restored from a backup, and the backup included required networks for the host cluster, configure the networks, attaching the relevant host NICs to these networks.
    • Once everything looks OK, and the host status is Up, remove the lock file presented in the message above. The deployment continues.

17. Select the type of storage to use:

    • For NFS, enter the version, full address and path to the storage, and any mount options.

      Warning

      Do not use the old self-hosted engine storage domain’s mount point for the new storage domain, as you risk losing virtual machine data.

    • For iSCSI, enter the portal details and select a target and LUN from the auto-detected lists. You can only select one iSCSI target during the deployment, but multipathing is supported to connect all portals of the same portal group.

      Note

      To specify more than one iSCSI target, you must enable multipathing before deploying the self-hosted engine. See Red Hat Enterprise Linux DM Multipath for details. There is also a Multipath Helper tool that generates a script to install and configure multipath with different options.

    • For Gluster storage, enter the full address and path to the storage, and any mount options.

      Warning

      Do not use the old self-hosted engine storage domain’s mount point for the new storage domain, as you risk losing virtual machine data.

      Important

      Only replica 1 and replica 3 Gluster storage are supported. Ensure you configure the volume as follows:

      gluster volume set VOLUME_NAME group virt
      gluster volume set VOLUME_NAME performance.strict-o-direct on
      gluster volume set VOLUME_NAME network.remote-dio off
      gluster volume set VOLUME_NAME storage.owner-uid 36
      gluster volume set VOLUME_NAME storage.owner-gid 36
      gluster volume set VOLUME_NAME network.ping-timeout 30

    • For Fibre Channel, select a LUN from the auto-detected list. The host bus adapters must be configured and connected, and the LUN must not contain any existing data. To reuse an existing LUN, see Reusing LUNs in the Administration Guide.

18. Enter the Manager disk size.

    The script continues until the deployment is complete.

19. The deployment process changes the Manager’s SSH keys. To allow client machines to access the new Manager without SSH errors, remove the original Manager’s entry from the .ssh/known_hosts file on any client machines that accessed the original Manager.

Procedure

1. Register your system with the Content Delivery Network, entering your Customer Portal user name and password when prompted:

   # subscription-manager register

   Note

   If you are using an IPv6 network, use an IPv6 transition mechanism to access the Content Delivery Network and subscription manager.

2. Find the Red Hat Virtualization Manager subscription pool and record the pool ID:

   # subscription-manager list --available

3. Use the pool ID to attach the subscription to the system:

   # subscription-manager attach --pool=pool_id

   Note

   To view currently attached subscriptions:

   # subscription-manager list --consumed

   To list all enabled repositories:

   # dnf repolist

4. Configure the repositories:

   # subscription-manager repos \
       --disable='*' \
       --enable=rhel-8-for-x86_64-baseos-eus-rpms \
       --enable=rhel-8-for-x86_64-appstream-eus-rpms \
       --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
       --enable=fast-datapath-for-rhel-8-x86_64-rpms \
       --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms \
       --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms \
       --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

5. Set the RHEL version to 8.6:

   # subscription-manager release --set=8.6

6. Enable the pki-deps module.

   # dnf module -y enable pki-deps

7. Enable version 12 of the postgresql module.

   # dnf module -y enable postgresql:12

8. Enable version 14 of the nodejs module:

   # dnf module -y enable nodejs:14

9. Synchronize installed packages to update them to the latest available versions.

   # dnf distro-sync --nobest

Procedure

1. Click Compute Hosts and select the host.
2. Click Management Maintenance and OK.
3. Click Installation Reinstall. This opens the Install Host window.
4. Click the Hosted Engine tab and select DEPLOY from the drop-down list.
5. Click OK to reinstall the host.

Procedure

1. Click Storage Domains.

2. Move the storage domain to maintenance mode and detach it:

   1. Click the storage domain’s name. This opens the details view.
   2. Click the Data Center tab.
   3. Click Maintenance, then click OK.
   4. Click Detach, then click OK.
3. Click Remove.
4. Optionally select the Format Domain, i.e. Storage Content will be lost! check box to erase the content of the domain.
5. Click OK.

Procedure

1. Log in to one of the self-hosted engine nodes and enable global maintenance mode:

   # hosted-engine --set-maintenance --mode=global

2. Confirm that the environment is in global maintenance mode before proceeding:

   # hosted-engine --vm-status

   You should see a message indicating that the cluster is in global maintenance mode.

Procedure

1. Log in to the Manager machine.

2. Remove the configuration files and clean the database associated with the Manager:

   # engine-cleanup

   The engine-cleanup command only cleans the Manager database; it does not drop the database or delete the user that owns that database.

3. Restore a full backup or a database-only backup. You do not need to create a new database or specify the database credentials because the user and database already exist.

   • Restore a full backup:

     # engine-backup --mode=restore --file=file_name --log=log_file_name --restore-permissions

   • Restore a database-only backup by restoring the configuration files and the database backup:

     # engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb --file=file_name --log=log_file_name --restore-permissions

     Note

     To restore only the Manager database (for example, if the Data Warehouse database is located on another machine), you can omit the --scope=dwhdb parameter.

     If successful, the following output displays:

     You should now run engine-setup.
     Done.

4. Reconfigure the Manager:

   # engine-setup

Procedure

1. Log in to the Manager virtual machine and shut it down.

2. Log in to one of the self-hosted engine nodes and disable global maintenance mode:

   # hosted-engine --set-maintenance --mode=none

   When you exit global maintenance mode, ovirt-ha-agent starts the Manager virtual machine, and then the Manager automatically starts. It can take up to ten minutes for the Manager to start.

3. Confirm that the environment is running:

   # hosted-engine --vm-status

   The listed information includes Engine Status. The value for Engine status should be:

   {"health": "good", "vm": "up", "detail": "Up"}

   Note

   When the virtual machine is still booting and the Manager hasn’t started yet, the Engine status is:

   {"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}

   If this happens, wait a few minutes and try again.

Procedure

1. Register your system with the Content Delivery Network, entering your Customer Portal user name and password when prompted:

   # subscription-manager register

   Note

   If you are using an IPv6 network, use an IPv6 transition mechanism to access the Content Delivery Network and subscription manager.

2. Find the Red Hat Virtualization Manager subscription pool and record the pool ID:

   # subscription-manager list --available

3. Use the pool ID to attach the subscription to the system:

   # subscription-manager attach --pool=pool_id

   Note

   To view currently attached subscriptions:

   # subscription-manager list --consumed

   To list all enabled repositories:

   # dnf repolist

4. Configure the repositories:

   # subscription-manager repos \
       --disable='*' \
       --enable=rhel-8-for-x86_64-baseos-eus-rpms \
       --enable=rhel-8-for-x86_64-appstream-eus-rpms \
       --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
       --enable=fast-datapath-for-rhel-8-x86_64-rpms \
       --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms \
       --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms \
       --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

5. Set the RHEL version to 8.6:

   # subscription-manager release --set=8.6

6. Enable version 12 of the postgresql module.

   # dnf module -y enable postgresql:12

7. Enable version 14 of the nodejs module:

   # dnf module -y enable nodejs:14

8. Synchronize installed packages to update them to the latest available versions.

   # dnf distro-sync --nobest

Procedure

1. Create a backup of the Data Warehouse database and configuration files on the Manager:

   # engine-backup --mode=backup --scope=grafanadb --scope=dwhdb --scope=files --file=file_name --log=log_file_name

2. Copy the backup file from the Manager to the new machine:

   # scp /tmp/file_name root@new.dwh.server.com:/tmp

3. Install engine-backup on the new machine:

   # dnf install ovirt-engine-tools-backup

4. Install the PostgreSQL server package:

   # dnf install postgresql-server postgresql-contrib

5. Initialize the PostgreSQL database, start the postgresql service, and ensure that this service starts on boot:

   # su - postgres -c 'initdb'
   # systemctl enable postgresql
   # systemctl start postgresql

6. Restore the Data Warehouse database on the new machine. file_name is the backup file copied from the Manager.

   # engine-backup --mode=restore --scope=files --scope=grafanadb --scope=dwhdb --file=file_name --log=log_file_name --provision-dwh-db

   When the --provision-* option is used in restore mode, --restore-permissions is applied by default.

1. Enable the required repositories:

   1. Register your system with the Content Delivery Network, entering your Customer Portal user name and password when prompted:

      # subscription-manager register

   2. Find the Red Hat Virtualization Manager subscription pool and record the pool ID:

      # subscription-manager list --available

   3. Use the pool ID to attach the subscription to the system:

      # subscription-manager attach --pool=pool_id

   4. Configure the repositories:

      # subscription-manager repos \
          --disable='*' \
          --enable=rhel-8-for-x86_64-baseos-eus-rpms \
          --enable=rhel-8-for-x86_64-appstream-eus-rpms \
          --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
          --enable=fast-datapath-for-rhel-8-x86_64-rpms \
          --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms
      
      # subscription-manager release --set=8.6

2. Enable the pki-deps module.

   # dnf module -y enable pki-deps

3. Ensure that all packages currently installed are up to date:

   # dnf upgrade --nobest

4. Install the ovirt-engine-dwh-setup package:

   # dnf install ovirt-engine-dwh-setup

Procedure

1. Stop the Data Warehouse service:

   # systemctl stop ovirt-engine-dwhd.service

2. If the database is hosted on a remote machine, you must manually grant access by editing the postgres.conf file. Edit the /var/lib/pgsql/data/postgresql.conf file and modify the listen_addresses line so that it matches the following:

   listen_addresses = '*'

   If the line does not exist or has been commented out, add it manually.

   If the database is hosted on the Manager machine and was configured during a clean setup of the Red Hat Virtualization Manager, access is granted by default.

3. Restart the postgresql service:

   # systemctl restart postgresql

1. If you are migrating both the ovirt_engine_history database and the Data Warehouse service to the same machine, run the following, otherwise proceed to the next step.

   # sed -i '/^ENGINE_DB_/d' \
           /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf
   
   # sed -i \
        -e 's;^\(OVESETUP_ENGINE_CORE/enable=bool\):True;\1:False;' \
        -e '/^OVESETUP_CONFIG\/fqdn/d' \
        /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

2. Remove the apache/grafana PKI files, so that they are regenerated by engine-setup with correct values:

   # rm -f \
     /etc/pki/ovirt-engine/certs/apache.cer \
     /etc/pki/ovirt-engine/certs/apache-grafana.cer \
     /etc/pki/ovirt-engine/keys/apache.key.nopass \
     /etc/pki/ovirt-engine/keys/apache-grafana.key.nopass \
     /etc/pki/ovirt-engine/apache-ca.pem \
     /etc/pki/ovirt-engine/apache-grafana-ca.pem

3. Run the engine-setup command to begin configuration of Data Warehouse on the machine:

   # engine-setup

4. Press Enter to accept the automatically detected host name, or enter an alternative host name and press Enter:

   Host fully qualified DNS name of this server [autodetected host name]:

5. Press Enter to automatically configure the firewall, or type No and press Enter to maintain existing settings:

   Setup can automatically configure the firewall on this system.
   Note: automatic configuration of the firewall may overwrite current settings.
   Do you want Setup to configure the firewall? (Yes, No) [Yes]:

   If you choose to automatically configure the firewall, and no firewall managers are active, you are prompted to select your chosen firewall manager from a list of supported options. Type the name of the firewall manager and press Enter. This applies even in cases where only one option is listed.

6. Enter the fully qualified domain name and password for the Manager. Press Enter to accept the default values in each other field:

   Host fully qualified DNS name of the engine server []: engine-fqdn
   Setup needs to do some actions on the remote engine server. Either automatically, using ssh as root to access it, or you will be prompted to manually perform each such action.
   Please choose one of the following:
   1 - Access remote engine server using ssh as root
   2 - Perform each action manually, use files to copy content around
   (1, 2) [1]:
   ssh port on remote engine server [22]:
   root password on remote engine server engine-fqdn: password

7. Enter the FQDN and password for the Manager database machine. Press Enter to accept the default values in each other field:

   Engine database host []: manager-db-fqdn
   Engine database port [5432]:
   Engine database secured connection (Yes, No) [No]:
   Engine database name [engine]:
   Engine database user [engine]:
   Engine database password: password

8. Confirm your installation settings:

   Please confirm installation settings (OK, Cancel) [OK]:

Procedure

1. On the Manager machine, restart the Manager:

   # service ovirt-engine restart

2. Run the following command to modify the file /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf and set the options to False:

   # sed -i \
        -e 's;^\(OVESETUP_DWH_CORE/enable=bool\):True;\1:False;' \
        -e 's;^\(OVESETUP_DWH_CONFIG/remoteEngineConfigured=bool\):True;\1:False;' \
        /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf
   
   # sed -i \
        -e 's;^\(OVESETUP_GRAFANA_CORE/enable=bool\):True;\1:False;' \
        /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

3. Disable the Data Warehouse service:

   # systemctl disable ovirt-engine-dwhd.service

4. Remove the Data Warehouse files:

   # rm -f /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/*.conf /var/lib/ovirt-engine-dwh/backups/*

1. The backup application uses the REST API to find virtual machine disks that should be included in the backup. Only disks in QCOW2 format are included.
2. The backup application starts a full backup or an incremental backup. The API call specifies a virtual machine ID, an optional previous checkpoint ID, and a list of disks to back up. If the API call does not specify a previous checkpoint ID, a full backup begins, which includes all data in the specified disks, based on the current state of each disk.
3. The engine prepares the virtual machine for backup. The virtual machine can continue running during the backup.
4. The backup application polls the engine for the backup status, until the engine reports that the backup is ready to begin.
5. When the backup is ready to begin, the backup application creates an image transfer object for every disk included in the backup.
6. The backup application gets a list of changed blocks from ovirt-imageio for every image transfer. If a change list is not available, the backup application gets an error.
7. The backup application downloads changed blocks in RAW format from ovirt-imageio and stores them in the backup media. If a list of changed blocks is not available, the backup application can fall back to copying the entire disk.
8. The backup application finalizes all image transfers.
9. The backup application finalizes the backup using the REST API.

1. The user selects a restore point based on available backups using the backup application.
2. The backup application creates a new disk or a snapshot with an existing disk to hold the restored data.
3. The backup application starts an upload image transfer for every disk, specifying format is raw. This enables format conversion when uploading RAW data to a QCOW2 disk.
4. The backup application transfers the data included in this restore point to imageio using the API.
5. The backup application finalizes the image transfers.

Procedure

1. Add a new virtual disk. For more information see Creating a Virtual Disk.
2. When configuring the disk, select the Enable Incremental Backup checkbox.

Procedure

1. In the Administration Portal, click Compute Virtual Machines.
2. Select a virtual machine and click the Disks tab.
3. Click the Edit button. The Edit Disk dialog box opens.
4. Select the Enable Incremental Backup checkbox.

Procedure

1. List the disks that are attached to the virtual machine. For example, for a virtual machine with the ID 123, send this request:

   GET /ovirt-engine/api/vms/123/diskattachments

   The response includes all disk_attachment objects, each of which includes one or more disk objects. For example:

   <disk_attachments>
       <disk_attachment>
          …​
          <disk href="/ovirt-engine/api/disks/456" id="456"/>
          …​
       </disk_attachment>
       …​
   </disk_attachments>

2. Use the disk service to see the properties of a disk from the previous step. For example, for the disk with the ID 456, send this request:

   GET /ovirt-engine/api/disks/456

   The response includes all properties for the disk. backup is set to none or incremental. For example:

   <disk href="/ovirt-engine/api/disks/456" id="456">
       …​
       <backup>incremental</backup>
       …​
   </disk>

Procedure

1. Send a request specifying a virtual machine to back up. For example, specify a virtual machine with ID 123 like this:

   POST /ovirt-engine/api/vms/123/backups

2. In the request body, specify a disk to back up. For example, to start a full backup of a disk with ID 456, send the following request body:

   <backup>
       <disks>
          <disk id="456" />
          …​
       </disks>
   </backup>

   The response body should look similar to this:

   <backup id="789">
       <disks>
          <disk id="456" />
          …​
          …​
       </disks>
       <status>initializing</status>
       <creation_date>
   </backup>

   The response includes the following:

   • The backup id
   • The status of the backup, indicating that the backup is initializing.
3. Poll the backup until the status is ready. The response includes to_checkpoint_id. Note this ID and use it for from_checkpoint_id in the next incremental backup.

Procedure

1. Send a request specifying a virtual machine to back up. For example, specify a virtual machine with ID 123 like this:

   POST /ovirt-engine/api/vms/123/backups

2. In the request body, specify a disk to back up. For example, to start an incremental backup of a disk with ID 456, send the following request body:

   <backup>
       <from_checkpoint_id>previous-checkpoint-uuid</from_checkpoint_id>
       <disks>
          <disk id="456" />
          …​
       </disks>
   </backup>

   Note

   In the request body, if you include a disk that is not included in the previous checkpoint, the request also runs a full backup of this disk. For example, a disk with ID 789 has not been backed up yet. To add a full backup of 789 to the above request body, send a request body like this:

   <backup>
       <from_checkpoint_id>previous-checkpoint-uuid</from_checkpoint_id>
       <disks>
          <disk id="456" />
          <disk id="789" />
          …​
       </disks>
   </backup>

   The response body should look similar to this:

   <backup id="101112">
   <from_checkpoint_id>previous-checkpoint-uuid</from_checkpoint_id>
   <to_checkpoint_id>new-checkpoint-uuid</to_checkpoint_id>
       <disks>
          <disk id="456" />
          <disk id="789" />
          …​
          …​
       </disks>
       <status>initializing</status>
       <creation_date>
   </backup>

   The response includes the following:

   • The backup ID.
   • The ID of any disk that was included in the backup.
   • The status, indicating that the backup is initializing.
3. Poll the backup until the status is ready. The response includes to_checkpoint_id. Note this ID and use it for from_checkpoint_id in the next incremental backup.

Procedure

1. Send a request like this:

   POST /ovirt-engine/api/imagetransfers

2. In the request body, specify the following parameters:

   • Disk ID.
   • Backup ID.
   • Direction of the disk set to download.
   • Format of the disk set to raw.

   For example, to transfer a backup of a disk where the ID of the disk is 123 and the ID of the backup is 456, send the following request body:

   <image_transfer>
       <disk id="123"/>
       <backup id="456"/>
       <direction>download</direction>
       <format>raw</format>
   </image_transfer>

Procedure

1. Send a request like this:

   POST /ovirt-engine/api/imagetransfers

2. In the request body, specify the following parameters:

   • Disk ID or snapshot ID.
   • Direction of the disk set to upload.
   • Format of the disk set to raw.

   For example, to transfer a backup of a disk where the ID of the disk is 123, send the following request body:

   <image_transfer>
       <disk id="123"/>
       <direction>upload</direction>
       <format>raw</format>
   </image_transfer>