diff --git a/content/product/cluster_configuration/backup_system/veeam.md b/content/product/cluster_configuration/backup_system/veeam.md index 81d890ed..4a61f4bf 100644 --- a/content/product/cluster_configuration/backup_system/veeam.md +++ b/content/product/cluster_configuration/backup_system/veeam.md @@ -111,24 +111,14 @@ The following table summarizes the supported backup modes for each storage syste ## Limitations -Here is a list of the known issues and limitations affecting the Veeam integration with OpenNebula: +Here is a list of the limitations affecting the Veeam integration with OpenNebula: - The KVM appliance in step 4.2 does not include context packages. This implies that in order to configure the networking of an appliance, you must either manually choose the first available free IP in the management network or set up a DHCP service router. - Alpine virtual machines cannot be backed up. - During image transfers, you may see a warning message stating ``Unable to use transfer URL for image transfer: Switched to proxy URL. Backup performance may be affected``. This is expected and shouldn't affect performance. - Spaces are not allowed in Virtual Machine names in the integration, so avoid using them (even if they are allowed in OpenNebula itself), otherwise you may face issues when performing an in-place restores of said VMs. -- If the backup chain is deleted in OpenNebula and an incremental is attempted from Veeam, the data may be corrupt, so a manual Full Backup is needed from Veeam, otherwise the incremental data will be missing. -- After performing a backup using Veeam VNC may stop working for the backed up VM and some configuration attributes may be lost. If facing this issue, please apply the following change to the ``/usr/lib/one/ovirtapi-server/controllers/backup_controller.rb`` file in the backup server at lines ~247-251 (the 2 ``vm.updateconf`` calls need the ``true`` statement at the end). Then, restart the apache2/httpd service: - -```ruby -... - vm.updateconf('BACKUP_CONFIG = ["MODE"="INCREMENT", "KEEP_LAST"="2",' \ - 'BACKUP_VOLATILE"="YES"]', true) -else - LOGGER.info 'Backup volatiles disabled.' - vm.updateconf('BACKUP_CONFIG = ["MODE"="INCREMENT", "KEEP_LAST"="2"]', true) -... -``` + +If facing other issues or bugs, we highly encourage to check the Veeam section of the [Known Issues page]({{% relref "../../../software/release_information/release_notes_70/known_issues/#backups---veeam" %}}). ## Architecture diff --git a/content/software/release_information/release_notes_70/known_issues.md b/content/software/release_information/release_notes_70/known_issues.md index cc91c4fc..2238be98 100644 --- a/content/software/release_information/release_notes_70/known_issues.md +++ b/content/software/release_information/release_notes_70/known_issues.md @@ -52,9 +52,33 @@ This page will be updated with relevant information about bugs affecting OpenNeb OpenNebula uses the `cirrus` graphical adapter for KVM Virtual Machines by default. It could happen that after installing a graphical desktop on a Linux VM, the Xorg window system does not load the appropriate video driver. You can force a VESA mode by configuring the kernel parameter `vga=VESA_MODE` in the GNU GRUB configuration file. [Here](https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers/) you can find the VESA mode numbers. For example, adding `vga=791` as kernel parameter will select the 16-bit 1024×768 resolution mode. -## Backups +## Backups - Veeam + +- If the backup chain is deleted in OpenNebula and an incremental is attempted from Veeam, the data may be corrupt, so a manual Full Backup is needed from Veeam, otherwise the incremental data will be missing. +- After performing a backup using Veeam VNC may stop working for the backed up VM and some configuration attributes may be lost. If facing this issue, please apply the following change to the ``/usr/lib/one/ovirtapi-server/controllers/backup_controller.rb`` file in the backup server at lines ~247-251 (the 2 ``vm.updateconf`` calls need the ``true`` statement at the end). Then, restart the apache2/httpd service: + +```ruby +... + vm.updateconf('BACKUP_CONFIG = ["MODE"="INCREMENT", "KEEP_LAST"="2",' \ + 'BACKUP_VOLATILE"="YES"]', true) # <- Add true parameter +else + LOGGER.info 'Backup volatiles disabled.' + vm.updateconf('BACKUP_CONFIG = ["MODE"="INCREMENT", "KEEP_LAST"="2"]', true) # <- Add true parameter +... +``` -- For Veeam related issues, please referer to the [Veeam (EE) page](../../../product/cluster_configuration/backup_system/veeam.md). +- In LVM environments, VM restores may fail to deploy if the restored VM is scheduled in the same host as the original VM (and the original is still deployed). To fix this, apply the following change to the ``/usr/lib/one/ovirtapi-server/controllers/vm_controller.rb`` file in the backup server at lines ~800. Then, restart the apache2/httpd service: + +```ruby +... +xml_element.delete_element('TEMPLATE/NIC') +xml_element.delete_element('TEMPLATE/DISK') +xml_element.delete_element('TEMPLATE/GRAPHICS') +xml_element.delete_element('TEMPLATE/OS/BOOT') +xml_element.delete_element('TEMPLATE/VMID') +xml_element.delete_element('TEMPLATE/OS/UUID') # <- Add this line +... +``` ## Market proxy settings