From b889d4233f4bed00d511a2a67a8aaf747781fd9b Mon Sep 17 00:00:00 2001 From: ArnauGabrielAtienza Date: Wed, 17 Dec 2025 16:31:00 +0100 Subject: [PATCH 1/3] fs freeze guides Signed-off-by: ArnauGabrielAtienza --- .../cluster_configuration/backup_system/veeam.md | 1 + .../virtual_machine_backups/operations.md | 10 ++++++++++ 2 files changed, 11 insertions(+) diff --git a/content/product/cluster_configuration/backup_system/veeam.md b/content/product/cluster_configuration/backup_system/veeam.md index 481f29221..4ce48cc02 100644 --- a/content/product/cluster_configuration/backup_system/veeam.md +++ b/content/product/cluster_configuration/backup_system/veeam.md @@ -228,6 +228,7 @@ The configuration file can be found at ``/etc/one/ovirtapi-server.yml``. You sho * ``one_xmlrpc``: Address of the OpenNebula Front-end. Please do not include any prefixes such as ``http://``, only the IP address itself is needed. * ``endpoint_port``: Port used by the OpenNebula RPC endpoint (defaults to 2633). * ``public_ip``: Address that Veeam is going to use to communicate with the ovirtapi server. +* ``backup_freeze``: (Optional) Controls which filesystem freeze mode OpenNebula requests when performing backups initiated via the oVirtAPI/Veeam integration. Valid values are `NONE`, `AGENT`, and `SUSPEND`. For details on each mode see the Backup Modes section in the backup guide: [Backup Modes]({{% relref "../../../product/virtual_machines_operation/virtual_machine_backups/operations/#backup-modes" %}}). {{< alert title="Important" color="success" >}} You may see the 5554 port in the ``public_ip`` variable in the default settings, this is no longer needed so avoid using it. Leave only the IP address in the variable, no port needed. diff --git a/content/product/virtual_machines_operation/virtual_machine_backups/operations.md b/content/product/virtual_machines_operation/virtual_machine_backups/operations.md index 14cf438dc..54003bbb8 100644 --- a/content/product/virtual_machines_operation/virtual_machine_backups/operations.md +++ b/content/product/virtual_machines_operation/virtual_machine_backups/operations.md @@ -61,6 +61,16 @@ In order to save space in the backup system, RAW disk backups are converted and Before making backups you need to configure some aspects of the backup process (e.g., the backup mode). This can be done for VM templates or Virtual Machines. +### Backup Modes + +OpenNebula provides three `FS_FREEZE` modes to control how the guest filesystem is handled before taking a backup. Choose the mode that best fits your workload and guest OS capabilities: + +- **NONE**: Do not attempt any filesystem freeze. This is the fastest option and requires no guest-side support, but backups may only be crash-consistent (the same as powering off the VM abruptly). Use when guest-agent support is unavailable or when minimal disruption is required. + +- **AGENT**: Use the guest agent to handle the filesystem inside the guest prior to backup. On Linux this typically uses the qemu guest agent or fsfreeze to freeze filesystems; on Windows the guest agent triggers the Volume Shadow Copy Service (VSS) to create application and filesystem-consistent snapshots (in this case VSS needs to be properly configured). `AGENT` is the recommended option when you need stronger consistency and the guest supports it. + +- **SUSPEND**: Suspend (pause) the VM at the hypervisor level for the brief period of the backup pre-step. This guarantees a consistent on-disk state without relying on guest tools, but it pauses all guest activity and may impact running services. + ### Virtual Machine Templates You can configure backups in the VM Template, so every VM created will have a preconfigured backup setup. The following example shows a VM template with incremental backups configured: From 226f6fd3b88b3b46c33761849536e0b2d5fa129f Mon Sep 17 00:00:00 2001 From: ArnauGabrielAtienza Date: Tue, 23 Dec 2025 16:45:35 +0100 Subject: [PATCH 2/3] updated veeam docs and issues Signed-off-by: ArnauGabrielAtienza --- .../backup_system/veeam.md | 74 +++++++++---------- .../release_notes_70/known_issues.md | 4 +- .../release_notes_70/resolved_issues_701.md | 1 + 3 files changed, 39 insertions(+), 40 deletions(-) diff --git a/content/product/cluster_configuration/backup_system/veeam.md b/content/product/cluster_configuration/backup_system/veeam.md index 4ce48cc02..3ad57f07f 100644 --- a/content/product/cluster_configuration/backup_system/veeam.md +++ b/content/product/cluster_configuration/backup_system/veeam.md @@ -62,62 +62,55 @@ The following table summarizes the supported backup modes for each storage syste - - - - - - - - - + + + - - - + - - + - - + - - - - + + + + +

Storage

Full

Incremental

Live

Power off

Live

Power off

Storage

Full

Incremental

File* (qcow2)

Yes

Yes

File (qcow2)

Yes

Yes

File* (raw)

Yes

File (raw)

Yes

No

No

No*

Ceph

Yes

Yes

No

No

LVM

Yes

Yes

Yes**

Yes**

NetApp

Yes

Yes
-\* Any datastore based on files with the given format, i.e., NFS/SAN or Local. +\* While OpenNebula doesn't support backups for raw images, Veeam will perform a full backup and perform block to block comparison to create it's own incremental. \** Supported for LVM-thin environments. ## 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 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 To ensure a compatible integration between OpenNebula and Veeam Backup, the following components and network configuration are required: @@ -147,7 +140,25 @@ The minimum hardware specifications are: - **CPU:** 8 cores - **Memory:** 16 GB RAM -- **Disk:** Sufficient storage to hold all active backups. This server acts as a staging area to transfer backups from OpenNebula to the Veeam repository, so its disk must be large enough to accommodate the total size of these backups. +- **Disk:** Sufficient storage to hold all active backup operations. See more details regarding the storage requirement in the next section. + +### Storage Requirements + +The Backup Server acts as a staging area between OpenNebula and the Veeam repository. It must provide enough disk capacity and I/O headroom for active backup and restore operations. Follow these practical guidelines when sizing and configuring storage: + +- **Primary backup datastore** (`/var/lib/one/datastores/`): this is where OpenNebula writes VM images and incremental chains before Veeam moves them to its repository. Size this datastore to hold the largest set of concurrently active backups you expect. + +- **Temporary restore area** (`/var/tmp`): when restoring a VM from a Veeam repository into OpenNebula, the restored image is staged here before being moved to the image datastore. Provision this directory to hold at least the largest single disk being restored (or the sum of concurrently restored disks if you will perform parallel restores). You can change this in the `tmp_images_path` parameter in the configuration. + +- **Retention and duplicate chains**: the backup will exist both in the OpenNebula backup datastore and in the Veeam repository. If you delete the chain from OpenNebula and Veeam subsequently runs an incremental, Veeam will perform a full backup and reconstruct incrementals itself. This increases transfer time but keeps backups consistent. If storage is constrained, schedule regular cleanup of old backup images in the OpenNebula datastore to free space, understanding that this may force full transfers on the next incremental run. + +- **Cleanup tooling**: the ovirtapi package includes a helper script to automate cleanup of the backup datastore: `/usr/lib/one/ovirtapi-server/scripts/backup_clean.rb`. You can run this script as the `oneadmin` user or schedule it via cron to maintain a maximum used threshold. Example crontab (daily at 00:00) to cap usage at 50%: + +```bash +0 0 * * * ONE_AUTH="oneadmin:oneadmin" MAX_USED_PERCENTAGE="50" /usr/lib/one/ovirtapi-server/scripts/backup_clean.rb +``` + +Ensure the `ONE_AUTH` variable is set to a valid OpenNebula `user:password` pair with permission to delete backup images. You may adjust `MAX_USED_PERCENTAGE` to a different threshold if desired. ## Veeam Backup Appliance Requirements @@ -177,8 +188,6 @@ The backup datastore must be created in the backup server configured in step 1. Here is an example of how to create an Rsync datastore in a Host named `backup-host` and then add it to a given cluster: ```bash -onedatastore create /tmp/rsync-datastore.txt - cat << EOF > /tmp/rsync-datastore.txt NAME="VeeamDS" DS_MAD="rsync" @@ -191,6 +200,8 @@ RSYNC_HOST="localhost" RSYNC_USER="oneadmin" SAFE_DIRS="/var/tmp" EOF + +onedatastore create /tmp/rsync-datastore.txt ``` 2.2. Add the datastore to the cluster @@ -204,20 +215,7 @@ SELinux and AppArmor may cause issues in the backup server if not configured pro You can find more details regarding the Rsync datastore in [Backup Datastore: Rsync]({{% relref "../../../product/cluster_configuration/backup_system/rsync.md" %}}). -**Sizing recommendations** - -The backup datastore needs to have enough space to hold the disks of the VMs that are going to be backed up. This introduces a layer of redundancy to the backups, as they will be stored in the OpenNebula Backup datastore and the Veeam Backup storage. This is something inherent to the Veeam integration with oVirt, as further backups of a Virtual Machine will be incremental and only the changed disk regions will be retrieved. - -If storage becomes a constraint, we recommend cleaning up the OpenNebula Backup datastore regularly in order to minimize the storage requirement, but keep in mind that this will reset the backup chain and force Veeam to perform a full backup and download the entire image during the next backup job. - -We provide alongside the ovirtapi package the ``/usr/lib/one/ovirtapi-server/scripts/backup_clean.rb`` script to aid in cleaning up the backup datastore. This script can be set up as a cronjob in the backup server with the oneadmin user. The following crontab example will run the script every day at 12:00 am and delete the oldest images until the backup datastore is under 50% capacity: -```bash -0 0 * * * ONE_AUTH="oneadmin:oneadmin" MAX_USED_PERCENTAGE="50" /path/to/your/script.sh -``` - -{{< alert title="Remember" color="success" >}} -For the ``/usr/lib/one/ovirtapi-server/scripts/backup_clean.rb`` script to work you need to set the ONE_AUTH environment variable to a valid ``user:password`` pair that can delete the backup images. You may also set the ``MAX_USED_PERCENTAGE`` variable to a different threshold (set to 50% by default).{{< /alert >}} ### 3. Install and configure the oVirtAPI module 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 395e79f81..b8d6965d3 100644 --- a/content/software/release_information/release_notes_70/known_issues.md +++ b/content/software/release_information/release_notes_70/known_issues.md @@ -48,9 +48,9 @@ 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 -- For Veeam related issues, please referer to the [Veeam (EE) page](../../../product/cluster_configuration/backup_system/veeam.md). +There are curently no issues reported from the Veeam integration. ## Market proxy settings diff --git a/content/software/release_information/release_notes_70/resolved_issues_701.md b/content/software/release_information/release_notes_70/resolved_issues_701.md index 04c2cfbdb..019cea219 100644 --- a/content/software/release_information/release_notes_70/resolved_issues_701.md +++ b/content/software/release_information/release_notes_70/resolved_issues_701.md @@ -89,3 +89,4 @@ The following issues have been solved in 7.0.1: - Fix Sunstone have snapshot button for the volatile disks but the operation is not permitted [#7184](https://github.com/OpenNebula/one/issues/7184) - Fix DRS: Parser sends incorrect datastore information to Optimizer [#7196](https://github.com/OpenNebula/one/issues/7196) - Fix OneFlow user_inputs are not per roles [#7213](https://github.com/OpenNebula/one/issues/7213) +- Fix LVM backups not working in Veeam [#7418](https://github.com/OpenNebula/one/issues/7418) \ No newline at end of file From f0cfdb4e42057f04300f90d0ed49036c258e1bec Mon Sep 17 00:00:00 2001 From: ArnauGabrielAtienza Date: Tue, 23 Dec 2025 17:18:55 +0100 Subject: [PATCH 3/3] move issue to correct file Signed-off-by: ArnauGabrielAtienza --- .../release_information/release_notes_70/resolved_issues_701.md | 1 - .../release_notes_enterprise/resolved_issues_703.md | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/content/software/release_information/release_notes_70/resolved_issues_701.md b/content/software/release_information/release_notes_70/resolved_issues_701.md index 019cea219..04c2cfbdb 100644 --- a/content/software/release_information/release_notes_70/resolved_issues_701.md +++ b/content/software/release_information/release_notes_70/resolved_issues_701.md @@ -89,4 +89,3 @@ The following issues have been solved in 7.0.1: - Fix Sunstone have snapshot button for the volatile disks but the operation is not permitted [#7184](https://github.com/OpenNebula/one/issues/7184) - Fix DRS: Parser sends incorrect datastore information to Optimizer [#7196](https://github.com/OpenNebula/one/issues/7196) - Fix OneFlow user_inputs are not per roles [#7213](https://github.com/OpenNebula/one/issues/7213) -- Fix LVM backups not working in Veeam [#7418](https://github.com/OpenNebula/one/issues/7418) \ No newline at end of file diff --git a/content/software/release_information/release_notes_enterprise/resolved_issues_703.md b/content/software/release_information/release_notes_enterprise/resolved_issues_703.md index 3587ae205..c24aa0bcf 100644 --- a/content/software/release_information/release_notes_enterprise/resolved_issues_703.md +++ b/content/software/release_information/release_notes_enterprise/resolved_issues_703.md @@ -15,3 +15,4 @@ The following issues have been solved in 7.0.3: - Fix WHMCS client Login action [#6879](https://github.com/OpenNebula/one/issues/6879) - Fix PCI device assignment mapping to the correct physical NUMA node when pinning is used [#7408](https://github.com/OpenNebula/one/issues/7408) - Fix missing ETHx_ROUTES attribute in the VM context section [#7348](https://github.com/OpenNebula/one/issues/7348) +- Fix LVM backups not working in Veeam [#7418](https://github.com/OpenNebula/one/issues/7418) \ No newline at end of file