M #-: Merge of 7.0 maintenance branch for 7.0.2 release

Author: rsmontero

assets/images/sunstone_cluster_evc_attributes.png

@@ -213,6 +213,15 @@ VMTEMPLATE
     ID: -1
 ```
 
+When an appliance is downloaded from the Marketplace, short hash values may be appended to object names to ensure uniqueness. This convention also applies to additional objects created during the download process, such as virtual machine templates and disks. To keep names easily identifiable, the original object name is preserved and placed before the appended hash and index. For example:
+```default
+$ oneimage list
+  ID USER     GROUP    NAME                                                                       DATASTORE     SIZE TYPE PER STAT RVMS
+  2 oneadmin oneadmin Windows VM Template_0-Contextualization Packages-aa38438e4a-2              default         2M CD    No rdy     0
+  1 oneadmin oneadmin Windows VM Template_0-Windows VirtIO Drivers - v0.1.285-e3cf06243b-1       default       754M CD    No rdy     0
+  0 oneadmin oneadmin Windows VM Template_0-Empty disk-fcee73d9e5-0                              default         5G OS    No rdy     0
+```
+
 <a id="marketapp-download"></a>
 
 You can also download an app to a standalone file in your desktop:

assets/images/sunstone_cluster_evc_update.png

@@ -45,6 +45,11 @@ The OpenNebula-Veeam® Backup Integration works by exposing a native **oVirt-
       <td style="min-width: 100px; border: 1px solid; vertical-align: top; padding: 5px;"><p>Full Discovery</p></td>
       <td style="min-width: 100px; border: 1px solid; vertical-align: top; padding: 5px;"><p>Veeam automatically discovers and displays the OpenNebula cluster hierarchy (clusters, hosts, VMs, and storage).</p></td>
     </tr>
+    <tr>
+      <td style="min-width: 100px; border: 1px solid; vertical-align: top; padding: 5px;"><p><strong>Portability</strong></p></td>
+      <td style="min-width: 100px; border: 1px solid; vertical-align: top; padding: 5px;"><p>VMWare import</p></td>
+      <td style="min-width: 100px; border: 1px solid; vertical-align: top; padding: 5px;"><p>Enables restoring virtual machines backed up in Veeam from VMWare into OpenNebula.</p></td>
+    </tr>
   </tbody>
 </table>
 
@@ -108,16 +113,10 @@ The following table summarizes the supported backup modes for each storage syste
 
 Here is a list of the known issues and limitations affecting the Veeam integration with OpenNebula:
 
-- Setting the ``PassengerMaxPoolSize`` variable to values higher than 1 can trigger issues depending on the system properties of the backup server and the amount of concurrent transfers, showing an error in the Veeam Backup & Replication console. If this happens too frequently, reduce the amount of concurrent Passenger processes to 1 until this issue is fixed.
 - 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.
-- There is an identified bug with Ceph image datastores that avoids the opennebula-ovirtapi package from uploading images into these kind of datastores, making restores and appliance deployments fail.
-- If a virtual network is owned by a user other than oneadmin (or the user chosen as the Veeam administrator in step 4.1) you may face an error when listing available networks.
-- Alphine 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.
+- 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.
-- Veeam may send multiple login token requests, which can cause to reach the OpenNebula token limit, causing backup failures if an backup was being performed when the token limit was reached.
-- Incremental backups may fail for VMs with more than 1 disk attached to them.
-- The number of VCPU in the KVM appliance may be set to 1 regardless of the configuration in Veeam. This can be solved by manually changing the number of vCPU in OpenNebula and restarting the VM. 
 
 ## Architecture
 
@@ -139,19 +138,23 @@ To ensure a compatible integration between OpenNebula and Veeam Backup, the foll
 
 To ensure full compatibility with the ovirtAPI module, the Backup Server must run one of the following operating systems:
 
-- AlmaLinux 8 or 9
+- AlmaLinux 9
 - Ubuntu 22.04 or 24.04
-- RHEL 8 or 9
-- Debian 11 or 12
+- RHEL 9
+- Debian 12
 
-The recommended hardware specifications are:
+The minimum hardware specifications are:
 
-- **CPU:** 4 cores
+- **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.
 
 ## Veeam Backup Appliance Requirements
+<<<<<<< HEAD
 When adding OpenNebula as a platform into Veeam, a KVM appliance will be deployed (step 4.2) as a VM into OpenNebula. This appliance has the following requirements:
+=======
+When adding OpenNebula as a platform into Veeam, a KVM appliance will be deployed (step 4.2) as a VM into OpenNebula. This appliance has the following minimum requirements:
+>>>>>>> one-7.0-maintenance
 
 - **CPU:** 6 cores
 - **Memory:** 6 GB RAM
@@ -161,11 +164,11 @@ Please make sure that there is an OpenNebula host with enough capacity for this
 
 ## Installation and Configuration
 
-1. Prepare the environment for the oVirtAPI Server
+### 1. Prepare the environment for the oVirtAPI Server
 
 A server should be configured to expose both the Rsync Backup datastore and the oVirtAPI Server. This server should be accessible from all the clusters that you want to be able to back up via the management network shown in the architecture diagram. The oVirtAPI Server is going to act as the communication gateway between Veeam and OpenNebula.
 
-2. Create a backup datastore
+### 2. Create a backup datastore
 
 The next step is to create a backup datastore in OpenNebula. This datastore will be used by the oVirtAPI module to handle the backup of the Virtual Machines before sending the backup data to Veeam. Currently only [Rsync Datastore]({{% relref "../../../product/cluster_configuration/backup_system/rsync.md" %}}) is supported. An additional property called ``VEEAM_DS`` must exist in the backup datastore template and be set to ``YES``.
 
@@ -215,7 +218,7 @@ We provide alongside the ovirtapi package the ``/usr/lib/one/ovirtapi-server/scr
 {{< 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
+### 3. Install and configure the oVirtAPI module
 
 In order to install the oVirtAPI module, you need to have the OpenNebula repository configured in the backup server. You can do so by following the instructions in [OpenNebula Repositories]({{% relref "../../../software/installation_process/manual_installation/opennebula_repository_configuration.md" %}}). Then, install the opennebula-ovirtapi package.
 
@@ -249,19 +252,11 @@ In RHEL and Alma environments, you may face issues with the passenger package de
 
 {{< /alert >}}
 
-#### Performance Improvements
-To increase the performance of the oVirtAPI module, you may want to modify the ammount of processes assigned to it to better utilize the CPUs available in the backup server. To do so, modify the ``PassengerMaxPoolSize`` parameters in the Apache configuration file to match the available CPUs. Depending on your distro it can be located in the following directories:
-
-* Debian/Ubuntu: ``/etc/apache2/sites-available/ovirtapi-server.conf``
-* Alma/RHEL: ``/etc/httpd/conf.d/ovirtapi-server.conf``
-
-After performing changes, restart the ``httpd`` or ``apache`` service.
-
-4. Add OpenNebula to Veeam
+### 4. Add OpenNebula to Veeam
 
 To add OpenNebula as a hypervisor to Veeam, configure it as an oVirt KVM Manager in Veeam and choose the IP address of the oVirtAPI module. You can follow the [official Veeam documentation](https://helpcenter.veeam.com/docs/vbrhv/userguide/connecting_manager.html?ver=6) for this step or follow the next steps:
 
-4.1 Add the new virtualization manager
+#### 4.1 Add the new virtualization manager
 
 The first step should be to add the ovirtAPI Backup server to Veeam. Head over to **Backup Infrastructure**, then to **Managed Servers**, and then click **Add Manager**:
 
@@ -287,7 +282,7 @@ As a last step, you can click finish and the new ovirtAPI server should be liste
 
 ![image](/images/veeam/hypervisor_added.png)
 
-4.2 Deploy the KVM appliance
+#### 4.2 Deploy the KVM appliance
 
 In order for Veeam to be able to perform backup and restore operations, it must deploy a dedicated Virtual Machine to act as a worker. To deploy it, go to the **Backup Infrastructure** tab, then **Backup Proxies**, and click **Add Proxy**:
 
@@ -319,7 +314,7 @@ In the next step, Veeam will take care of deploying the appliance. Once finished
 
 ![image](/images/veeam/appliance_listed.png)
 
-4.3 Verification
+#### 4.3 Verification
 
 If everything is set properly, you should be able to see the available Virtual Machines in the **Inventory** tab under the **Virtual Infrastructure** -> **oVirt KVM** section.
 
@@ -333,6 +328,47 @@ The ovirtapi server will generate logs in the following directory depending on t
 * Alma/RHEL: ``/var/log/httpd``
 
 If you use the cleanup script provided at ``/usr/lib/one/ovirtapi-server/scripts/backup_clean.rb``, the cleanup logs will be placed at ``/var/log/one/backup_cleaner_script.log``.
+<<<<<<< HEAD
+=======
+
+## Performance Improvements
+
+To improve image transfer speed, you can increase the number of concurrent processes to better utilize the backup server's resources. This is controlled by the ``PassengerMaxPoolSize`` parameter in your Apache configuration file.
+
+### Adjusting the Process Pool
+
+You can find the configuration file in the following locations, depending on your distribution:
+
+* Debian/Ubuntu: ``/etc/apache2/sites-available/ovirtapi-server.conf``
+* Alma/RHEL: ``/etc/httpd/conf.d/ovirtapi-server.conf``
+
+After editing and saving the file, you must restart the webserver for the change to take effect:
+
+* Debian/Ubuntu: ``sudo systemctl restart apache2``
+* Alma/RHEL: ``sudo systemctl restart httpd``
+
+### Adjusting the Process Pool
+
+When setting the ``PassengerMaxPoolSize``, you must balance RAM and CPU availability.
+
+**Memory**
+
+Each active Passenger process consumes approximately 150-200 MB of RAM. You can use the following formula as a starting point to determine a safe maximum, leaving a 30% buffer for the OS and other services:
+
+``(TOTAL_SERVER_RAM_MB * 0.70) / 200 = Recommended MaxPoolSize``
+
+**CPU**
+
+While increasing the pool size, monitor your CPU usage during active transfers. If the CPU load becomes the bottleneck (consistently high usage), adding more processes won't increase speed and may even slow things down. In that case, you will need to increase the number of CPUs or vCPUs assigned to the backup server.
+
+### Interpreting Veeam Job Statistics
+
+The Veeam job statistics window shows a breakdown of the load, which is crucial for identifying the true bottleneck in your backup chain.
+
+* **Source:** This represents your backup server. A high load (e.g., 99%) here is ideal. It means your server is working at full capacity and that the bottleneck is correctly placed on the source, not on other components.
+* **Proxy:** This is the KVM appliance deployed by Veeam. If its load is consistently high (e.g., >90%), it is the bottleneck and requires more resources (vCPU/RAM).
+* **Network:** This indicates that the transfer speed is being limited by the available bandwidth on the management network connecting the components.
+>>>>>>> one-7.0-maintenance
 
 ## Volatile disk backups
 

content/product/apps-marketplace/managing_marketplaces/marketapps.md

@@ -146,3 +146,58 @@ The [Sunstone UI interface]({{% relref "../../control_plane_configuration/graphi
 - See cluster details and update overcommitment.
 
 ![details_cluster](/images/sunstone_cluster_details.png)
+
+## Enhanced VM Compatibility (EVC)
+
+The Enhanced VM Compatibility (EVC) feature facilitates the management of heterogeneous OpenNebula clusters by masking host CPU capabilities to enforce a unified base model. Using a lowest-common-denominator approach ensures CPU compatibility across hosts and enables seamless live migration of Virtual Machines between hosts with different processor generations.
+
+EVC is configured at the cluster level. This simplifies management and improves scalability by allowing administrators to add newer hardware to existing clusters without preventing VM migration due to CPU differences.
+
+### Using EVC with the CLI
+
+1. Inspect the cluster to view the current template and attributes:
+
+```bash
+$ onecluster show default
+```
+
+Look for the `CLUSTER TEMPLATE` section. If `EVC_MODE` is not present, it has not been configured for the cluster.
+
+2. Set the `EVC_MODE` attribute on a cluster using `onecluster update`. For example, to set a Sandy Bridge baseline:
+
+```bash
+$ onecluster update default"
+```
+
+Then add the `EVC_MODE` attribute to the list:
+
+```bash
+...
+EVC_MODE="sandybridge"
+...
+```
+
+The exact CPU model string depends on the hypervisor's supported CPU map. You can view the supported cpu models of a given host with the following command under the `KVM_CPU_MODELS` key:
+
+```bash
+$ onehost show <host-id> -j
+```
+
+Make sure to select a cpu model available in all hosts in the cluster, otherwise you may fail to deploy VMs on unsupported hosts. 
+
+
+3. To revert or remove EVC, update the cluster template to remove the `EVC_MODE` attribute (for example by setting it to an empty string or re-applying a template without the attribute).
+
+### Using EVC with Sunstone
+
+The Fireedge / Sunstone web UI provides a convenient way to enable and change EVC without editing templates directly.
+
+1. Open the Infrastructure → Clusters view and select the cluster you want to configure.
+
+2. Click the Update button and go to the Select Hosts tabs, there you will see the EVC Mode section. To enable EVC, choose a model from the droplist. Afterwards you can click Finish.
+
+![Update cluster EVC mode](/images/sunstone_cluster_evc_update.png)
+
+3. Once the EVC mode is set, you can see it listed in the cluster attributes the same way as if the CLI had been used.
+
+![EVC set in cluster attributes](/images/sunstone_cluster_evc_attributes.png)

content/product/cluster_configuration/backup_system/veeam.md

@@ -179,7 +179,6 @@ $ cat netapp_system.ds
 NAME              = "netapp_system"
 TYPE              = "SYSTEM_DS"
 DISK_TYPE         = "BLOCK"
-DS_MAD            = "netapp"
 TM_MAD            = "netapp"
 NETAPP_HOST       = "10.1.234.56"
 NETAPP_USER       = "admin"
@@ -219,6 +218,7 @@ $ cat netapp_image.ds
 NAME              = "netapp_image"
 TYPE              = "IMAGE_DS"
 DISK_TYPE         = "BLOCK"
+DS_MAD            = "netapp"
 TM_MAD            = "netapp"
 NETAPP_HOST       = "10.1.234.56"
 NETAPP_USER       = "admin"
@@ -241,9 +241,10 @@ Since Volumes contain the LUNs and snapshots, they are by default configured to
 | Attribute                 | Description                                           |
 | ------------------------- | ----------------------------------------------------- |
 | `NETAPP_SUFFIX`           | Volume/LUN name suffix.                               |
-| `NETAPP_GROW_THRESHOLD`   | Volume autogrow threshold in percent. Default: 96     |
+| `NETAPP_GROW_THRESHOLD`   | Volume autogrow threshold in percent. Default: 90     |
 | `NETAPP_GROW_RATIO`       | Volume maximum autogrow ratio. Default: 2             |
 | `NETAPP_SNAPSHOT_RESERVE` | Volume snapshot reserve in percent. Default: 10       |
+| `NETAPP_STANDALONE`       | Volume FlexClones always split. Default: NO           |
 
 {{< alert title="Note" color="success" >}}
 Volumes will be created with the extra reservation space in mind, which will be `size * ( 1 + NETAPP_SNAPSHOT_RESERVE / 100 )`.
@@ -258,7 +259,7 @@ Volumes will be created with the extra reservation space in mind, which will be
   - Image datastore: `one_<datastore_id>_<image_id>` (volume), `one_<datastore_id>_<image_id>_lun` (LUN)
   - System datastore: `one_<vm_id>_disk_<disk_id>` (volume), `one_<datastore_id>_<vm_id>_disk_<disk_id>_lun` (LUN)
 - **Operations:**
-  - Non‐persistent: FlexClone, then split
+  - Non‐persistent: FlexClone, optionally split when `NETAPP_STANDALONE="YES"`
   - Persistent: Rename
 
 Symbolic links from the System datastore will be created for each Virtual Machine on its Host once the LUNs have been mapped.
@@ -267,9 +268,19 @@ Symbolic links from the System datastore will be created for each Virtual Machin
 The minimum size for a NetApp volume is 20 MB, so any disk smaller than that will result in a 20 MB volume; however, the LUN inside will be the correct size.
 {{< /alert >}}
 
-## Known Issues
+**Backups process details:**
+
+Both Full and Incremental backups are supported by NetApp. For Full Backups, a snapshot of the Volume containing the VM disk LUN is taken and attached to the host, where it is converted into a qcow2 image and uploaded to the backup datastore. 
+
+Incremental backups are created by first creating the base full backup from the snapshot however this snapshot is then retained on the NetApp Volume rather than deleted after the backup is taken. When another incremental backup is taken, a new snapshot is taken and both the previous and current snapshots are cloned to new Volumes where they are attached to the host and compared for differences at the block level. These block changes are stored in a sparse QCOW2 file backed by the previous snapshot, which is then uploaded to the backup datastore.  The old snapshot is then removed while the new one is retained. When incremental backups are restored, the backing chain is rebuilt before restoring the backup to the VM disk.
 
-Currently the NetApp password on the Datastore is not encrypted due to a typo in the configuration file `/etc/one/oned.conf`. To encrypt this password, the Encrypted Attributes section of this file you must change `DATASTORE_ENCRYPTED_ATTR = "NETAPP_PASSWORD"` to `DATASTORE_ENCRYPTED_ATTR = "NETAPP_PASS"` and then restart OpenNebula.
+{{< alert title="Note" color="success" >}}
+You can configure the block size ( Defualt 2097152 B / 2 MB ) for incremental backups by modifing the file at `/var/tmp/one/etc/tm/san/backup.conf`
+{{< /alert >}}
+
+{{< alert title="Warning" color="warning" >}}
+The incremental backup feature of NetApp requires the `nbd` kernel module to be loaded and the `nbdfuse` package to be installed on all OpenNebula nodes.
+{{< /alert >}}
 
 ## System Considerations