Skip to content

Commit 94d3944

Browse files
B OpenNebula/one#7418: Updated veeam known issues (#480)
1 parent 8aee778 commit 94d3944

File tree

2 files changed

+29
-15
lines changed
  • content

2 files changed

+29
-15
lines changed

content/product/cluster_configuration/backup_system/veeam.md

Lines changed: 3 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -111,24 +111,14 @@ The following table summarizes the supported backup modes for each storage syste
111111

112112
## Limitations
113113

114-
Here is a list of the known issues and limitations affecting the Veeam integration with OpenNebula:
114+
Here is a list of the limitations affecting the Veeam integration with OpenNebula:
115115

116116
- 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.
117117
- Alpine virtual machines cannot be backed up.
118118
- 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.
119119
- 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.
120-
- 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.
121-
- 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:
122-
123-
```ruby
124-
...
125-
vm.updateconf('BACKUP_CONFIG = ["MODE"="INCREMENT", "KEEP_LAST"="2",' \
126-
'BACKUP_VOLATILE"="YES"]', true)
127-
else
128-
LOGGER.info 'Backup volatiles disabled.'
129-
vm.updateconf('BACKUP_CONFIG = ["MODE"="INCREMENT", "KEEP_LAST"="2"]', true)
130-
...
131-
```
120+
121+
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" %}}).
132122

133123
## Architecture
134124

content/software/release_information/release_notes_70/known_issues.md

Lines changed: 26 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -52,9 +52,33 @@ This page will be updated with relevant information about bugs affecting OpenNeb
5252
5353
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.
5454

55-
## Backups
55+
## Backups - Veeam
56+
57+
- 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.
58+
- 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:
59+
60+
```ruby
61+
...
62+
vm.updateconf('BACKUP_CONFIG = ["MODE"="INCREMENT", "KEEP_LAST"="2",' \
63+
'BACKUP_VOLATILE"="YES"]', true) # <- Add true parameter
64+
else
65+
LOGGER.info 'Backup volatiles disabled.'
66+
vm.updateconf('BACKUP_CONFIG = ["MODE"="INCREMENT", "KEEP_LAST"="2"]', true) # <- Add true parameter
67+
...
68+
```
5669

57-
- For Veeam related issues, please referer to the [Veeam (EE) page](../../../product/cluster_configuration/backup_system/veeam.md).
70+
- 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:
71+
72+
```ruby
73+
...
74+
xml_element.delete_element('TEMPLATE/NIC')
75+
xml_element.delete_element('TEMPLATE/DISK')
76+
xml_element.delete_element('TEMPLATE/GRAPHICS')
77+
xml_element.delete_element('TEMPLATE/OS/BOOT')
78+
xml_element.delete_element('TEMPLATE/VMID')
79+
xml_element.delete_element('TEMPLATE/OS/UUID') # <- Add this line
80+
...
81+
```
5882

5983
## Market proxy settings
6084

0 commit comments

Comments
 (0)