diff --git a/assets/images/backup_veeam_architecture.png b/assets/images/backup_veeam_architecture.png
deleted file mode 100644
index 29c21e046..000000000
Binary files a/assets/images/backup_veeam_architecture.png and /dev/null differ
diff --git a/assets/images/backup_veeam_architecture.svg b/assets/images/backup_veeam_architecture.svg
new file mode 100644
index 000000000..f01c4f057
--- /dev/null
+++ b/assets/images/backup_veeam_architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/collector.png b/assets/images/collector.png
deleted file mode 100644
index e27ba85de..000000000
Binary files a/assets/images/collector.png and /dev/null differ
diff --git a/assets/images/collector.svg b/assets/images/collector.svg
new file mode 100644
index 000000000..b8379ba68
--- /dev/null
+++ b/assets/images/collector.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/datastoreoverview.png b/assets/images/datastoreoverview.png
deleted file mode 100644
index df618ab3f..000000000
Binary files a/assets/images/datastoreoverview.png and /dev/null differ
diff --git a/assets/images/datastoreoverview.svg b/assets/images/datastoreoverview.svg
new file mode 100644
index 000000000..e74baa92c
--- /dev/null
+++ b/assets/images/datastoreoverview.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/fs_shared.png b/assets/images/fs_shared.png
deleted file mode 100644
index f13cf2aa2..000000000
Binary files a/assets/images/fs_shared.png and /dev/null differ
diff --git a/assets/images/fs_shared.svg b/assets/images/fs_shared.svg
new file mode 100644
index 000000000..91841aea5
--- /dev/null
+++ b/assets/images/fs_shared.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/fs_ssh.png b/assets/images/fs_ssh.png
deleted file mode 100644
index 4cdb462e0..000000000
Binary files a/assets/images/fs_ssh.png and /dev/null differ
diff --git a/assets/images/fs_ssh.svg b/assets/images/fs_ssh.svg
new file mode 100644
index 000000000..6552a835b
--- /dev/null
+++ b/assets/images/fs_ssh.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/hooks-subsystem-architecture.png b/assets/images/hooks-subsystem-architecture.png
deleted file mode 100644
index 18de0cc25..000000000
Binary files a/assets/images/hooks-subsystem-architecture.png and /dev/null differ
diff --git a/assets/images/hooks-subsystem-architecture.svg b/assets/images/hooks-subsystem-architecture.svg
new file mode 100644
index 000000000..702f615ca
--- /dev/null
+++ b/assets/images/hooks-subsystem-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/local_ds_cache.png b/assets/images/local_ds_cache.png
deleted file mode 100644
index 48cdecd5b..000000000
Binary files a/assets/images/local_ds_cache.png and /dev/null differ
diff --git a/assets/images/local_ds_cache.svg b/assets/images/local_ds_cache.svg
new file mode 100644
index 000000000..76ad42f68
--- /dev/null
+++ b/assets/images/local_ds_cache.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/market_http.png b/assets/images/market_http.png
deleted file mode 100644
index e074c5ebb..000000000
Binary files a/assets/images/market_http.png and /dev/null differ
diff --git a/assets/images/market_http.svg b/assets/images/market_http.svg
new file mode 100644
index 000000000..9c485c153
--- /dev/null
+++ b/assets/images/market_http.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/one_scalability.jpg b/assets/images/one_scalability.jpg
deleted file mode 100644
index 03736d32b..000000000
Binary files a/assets/images/one_scalability.jpg and /dev/null differ
diff --git a/assets/images/one_scalability.png b/assets/images/one_scalability.png
deleted file mode 100644
index a22426d5a..000000000
Binary files a/assets/images/one_scalability.png and /dev/null differ
diff --git a/assets/images/one_scalability.svg b/assets/images/one_scalability.svg
new file mode 100644
index 000000000..0a88e6949
--- /dev/null
+++ b/assets/images/one_scalability.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/oneflow-network-map.png b/assets/images/oneflow-network-map.png
deleted file mode 100644
index b5f4cb14e..000000000
Binary files a/assets/images/oneflow-network-map.png and /dev/null differ
diff --git a/assets/images/oneflow-network-map.svg b/assets/images/oneflow-network-map.svg
new file mode 100644
index 000000000..c020c6cf2
--- /dev/null
+++ b/assets/images/oneflow-network-map.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/onegate_arch.png b/assets/images/onegate_arch.png
deleted file mode 100644
index 9cbebcf65..000000000
Binary files a/assets/images/onegate_arch.png and /dev/null differ
diff --git a/assets/images/onegate_arch.svg b/assets/images/onegate_arch.svg
new file mode 100644
index 000000000..f16bc2c82
--- /dev/null
+++ b/assets/images/onegate_arch.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/overview_customized-cluster.png b/assets/images/overview_customized-cluster.png
deleted file mode 100644
index b27992bd7..000000000
Binary files a/assets/images/overview_customized-cluster.png and /dev/null differ
diff --git a/assets/images/overview_customized-cluster.svg b/assets/images/overview_customized-cluster.svg
new file mode 100644
index 000000000..50409225e
--- /dev/null
+++ b/assets/images/overview_customized-cluster.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/scheduler_architecture.png b/assets/images/scheduler_architecture.png
deleted file mode 100644
index 2238ddb4b..000000000
Binary files a/assets/images/scheduler_architecture.png and /dev/null differ
diff --git a/assets/images/scheduler_architecture.svg b/assets/images/scheduler_architecture.svg
new file mode 100644
index 000000000..1c1456407
--- /dev/null
+++ b/assets/images/scheduler_architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/service_sample.png b/assets/images/service_sample.png
deleted file mode 100644
index b727de4f4..000000000
Binary files a/assets/images/service_sample.png and /dev/null differ
diff --git a/assets/images/service_sample.svg b/assets/images/service_sample.svg
new file mode 100644
index 000000000..9fc5bd0fb
--- /dev/null
+++ b/assets/images/service_sample.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/content/getting_started/understand_opennebula/opennebula_concepts/opennebula_overview.md b/content/getting_started/understand_opennebula/opennebula_concepts/opennebula_overview.md
index 17c1d0184..3e1bb8172 100644
--- a/content/getting_started/understand_opennebula/opennebula_concepts/opennebula_overview.md
+++ b/content/getting_started/understand_opennebula/opennebula_concepts/opennebula_overview.md
@@ -88,9 +88,7 @@ OpenNebula is certified to work on top of multiple combinations of hypervisors,
If you are interested in an OpenNebula cloud fully based on open source platforms and technologies, please refer to our [Open Cloud Reference Architecture](https://support.opennebula.pro/hc/en-us/articles/204210319).
-
-
-
+{{< image path="/images/overview_customized-cluster.svg" alt="OpenNebula Cloud Model based on Customized Clusters" align="center" width="70%" pb="20px" >}}
### Choosing the Right Configuration
diff --git a/content/product/apps-marketplace/private_marketplaces/market_http.md b/content/product/apps-marketplace/private_marketplaces/market_http.md
index 38e0a437e..daf3f1d90 100644
--- a/content/product/apps-marketplace/private_marketplaces/market_http.md
+++ b/content/product/apps-marketplace/private_marketplaces/market_http.md
@@ -43,7 +43,7 @@ These are the configuration attributes of a Marketplace template of the HTTP kin
When an image is uploaded to this market, it is copied to `BRIDGE_LIST`:`PUBLIC_DIR` (if `BRIDGE_LIST` is not set, then it is copied to the current Front-end where OpenNebula is running). After that, it is available in `BASE_URL`. OpenNebula does not set up the webserver nor the secure access to it.
-
+{{< image path="/images/market_http.svg" alt="HTTP marketplace overview" align="center" width="80%" pb="20px" >}}
For example, the following examples illustrate the creation of a Marketplace:
diff --git a/content/product/cloud_system_administration/resource_monitoring/monitoring_system.md b/content/product/cloud_system_administration/resource_monitoring/monitoring_system.md
index 357bab42b..8ab944567 100644
--- a/content/product/cloud_system_administration/resource_monitoring/monitoring_system.md
+++ b/content/product/cloud_system_administration/resource_monitoring/monitoring_system.md
@@ -26,7 +26,7 @@ As part of the regular start process, OpenNebula starts the `onemonitord` daemon
Probes are structured in information categories for Host and Virtual Machine information. At regular intervals (in seconds, configurable per category in the `monitord.conf`) the data is transmitted, so the monitoring subsystem doesn’t need to make any additional connections to gather it.
-
+{{< image path="/images/collector.svg" alt="Architecture of Dedicated Monitoring System in OpenNebula" align="center" width="70%" pb="20px" >}}
If information stops coming from a specific Host, OpenNebula detects it by missing heartbeats and pro-actively connects to the particular Host over SSH and restarts probes.
diff --git a/content/product/cloud_system_administration/scheduler/overview.md b/content/product/cloud_system_administration/scheduler/overview.md
index 230873627..67f245fdd 100644
--- a/content/product/cloud_system_administration/scheduler/overview.md
+++ b/content/product/cloud_system_administration/scheduler/overview.md
@@ -153,7 +153,7 @@ OpenNebula continuously optimizes cluster workload distribution using the [OpenN
The diagram below outlines the OpenNebula Scheduling Framework, showing key components for resource selection and workload optimization:
-
+{{< image path="/images/scheduler_architecture.svg" alt="Scheduler Architecture" align="center" width="70%" pb="20px" >}}
Main components:
diff --git a/content/product/cluster_configuration/backup_system/veeam.md b/content/product/cluster_configuration/backup_system/veeam.md
index 481f29221..e183cc311 100644
--- a/content/product/cluster_configuration/backup_system/veeam.md
+++ b/content/product/cluster_configuration/backup_system/veeam.md
@@ -132,7 +132,7 @@ To ensure a compatible integration between OpenNebula and Veeam Backup, the foll
- Veeam Backup appliance
-
+{{< image path="/images/backup_veeam_architecture.svg" alt="Architecture of the OpenNebula-Veeam Backup Integration" align="center" width="70%" pb="20px" >}}
## Backup Server Requirements
diff --git a/content/product/cluster_configuration/san_storage/lvm_drivers.md b/content/product/cluster_configuration/san_storage/lvm_drivers.md
index 65cb5ef3e..9f33488fe 100644
--- a/content/product/cluster_configuration/san_storage/lvm_drivers.md
+++ b/content/product/cluster_configuration/san_storage/lvm_drivers.md
@@ -332,7 +332,8 @@ Before adding a new filesystem to the `SUPPORTED_FS` list make sure that the cor
Images are stored as regular files (under the usual path: `/var/lib/one/datastores/`) in the Image Datastore, but they will be dumped into a Logical Volumes (LV) upon Virtual Machine creation. The Virtual Machines will run from Logical Volumes in the Host.
-
+{{< image path="/images/fs_lvm_datastore.svg" alt="Images stored as regular files dumped into LVs" align="center" width="70%" pb="20px" >}}
+
{{< alert title="Note" color="success" >}}
Files are dumped directly from the Front-end to the LVs in the Host, using the SSH protocol.{{< /alert >}}
diff --git a/content/product/cluster_configuration/storage_system/local_ds.md b/content/product/cluster_configuration/storage_system/local_ds.md
index 0db7de6b7..bd9a0e2c7 100644
--- a/content/product/cluster_configuration/storage_system/local_ds.md
+++ b/content/product/cluster_configuration/storage_system/local_ds.md
@@ -141,7 +141,7 @@ The canonical path for `/var/lib/one/datastores` can be changed in [/etc/one/one
In this case, the System Datastore is distributed among the Hosts. The **local** transfer driver uses the Hosts' local storage to place the images of running Virtual Machines. All of the operations are then performed locally, but images still need to be copied to the Hosts, which can be a very resource-demanding operation.
-
+{{< image path="/images/fs_ssh.svg" alt="Overview of Datastore Internals" align="center" width="70%" pb="20px" >}}
## Distributed Cache
@@ -163,7 +163,7 @@ When a VM is launched:
Once the cache manager downloads the image, this is stored in both the _local_ and _central_ caches for future use.
-
+{{< image path="/images/local_ds_cache.svg" alt="Speeding up VM provisioning with Distributed Cache" align="center" width="70%" pb="20px" >}}
## How to Enable and Configure the Cache
diff --git a/content/product/cluster_configuration/storage_system/nas_ds.md b/content/product/cluster_configuration/storage_system/nas_ds.md
index 0faa4c616..794dfa473 100644
--- a/content/product/cluster_configuration/storage_system/nas_ds.md
+++ b/content/product/cluster_configuration/storage_system/nas_ds.md
@@ -206,4 +206,5 @@ The `shared` transfer driver assumes that the datastore is mounted on all the Ho
When a VM is created, its disks (the `disk.i` files) are copied or linked in the corresponding directory of the System Datastore. These file operations are always performed remotely on the target Host.
-
+{{< image path="/images/fs_shared.svg" alt="VM disks linked in the System Datastore directory" align="center" width="60%" pb="20px" >}}
+
diff --git a/content/product/cluster_configuration/storage_system/overview.md b/content/product/cluster_configuration/storage_system/overview.md
index 93ab8af92..675a61085 100644
--- a/content/product/cluster_configuration/storage_system/overview.md
+++ b/content/product/cluster_configuration/storage_system/overview.md
@@ -22,7 +22,7 @@ Storage in OpenNebula is designed around the concept of datastores. A datastore
* **System Datastore** holds disks of running Virtual Machines. Disk are moved from/to the Images when the VMs are deployed/terminated.
* **Files & Kernels Datastore** to store plain files (not disk images), e.g. kernels, ramdisks, or contextualization files. [See details here]({{% relref "file_ds#file-ds" %}}).
-
+{{< image path="/images/datastoreoverview.svg" alt="Overview of Storage Design based on Datastores" align="center" width="50%" pb="20px" >}}
### Image Datastores
diff --git a/content/product/control_plane_configuration/large-scale_deployment/scalability.md b/content/product/control_plane_configuration/large-scale_deployment/scalability.md
index f80cbd6bc..f8fb1f319 100644
--- a/content/product/control_plane_configuration/large-scale_deployment/scalability.md
+++ b/content/product/control_plane_configuration/large-scale_deployment/scalability.md
@@ -161,7 +161,7 @@ Read-only operations enforce any ACL restriction or ownership checks.{{< /alert
Any other API call is forwarded to the active oned process. In this case, the cache server is acting as a simple proxy. The architecture recommended to be used with the cache server is depicted in the following figure:
-
+{{< image path="/images/one_scalability.svg" alt="Architecture used with the cache server for API calls" align="center" width="60%" pb="20px" >}}
When the Master oned is actually a RAFT cluster, you can simply point the API servers to the VIP address of the cluster. Note also that the MySQL server in each RAFT server should be configured to listen to the VIP address to let the API servers query the database.
diff --git a/content/product/integration_references/system_interfaces/hook_driver.md b/content/product/integration_references/system_interfaces/hook_driver.md
index 268c8cf3a..e808852a0 100644
--- a/content/product/integration_references/system_interfaces/hook_driver.md
+++ b/content/product/integration_references/system_interfaces/hook_driver.md
@@ -21,7 +21,7 @@ The hook subsystem has two main components:
- **Hook Manager Driver**: it receives information about every event triggered by the OpenNebula service and publishes it to an event queue. Custom components can also use this queue to subscribe to OpenNebula events, [more information here]({{% relref "#hook-manager-events" %}}).
- **Hook Execution Manager** (HEM): it registers itself to the events that trigger the hooks defined in the system. When an event is received it takes care of executing the corresponding hook command.
-
+{{< image path="/images/hooks-subsystem-architecture.svg" alt="Hook Subsystem" align="center" width="70%" pb="20px" >}}
Both components are started together with the OpenNebula service. Note that, provided the network communication is secure, you can grant network access to the event queue and hence deploy HEM in a different server.
diff --git a/content/product/virtual_machines_operation/multi-vm_workflows/appflow_use_cli.md b/content/product/virtual_machines_operation/multi-vm_workflows/appflow_use_cli.md
index 6a97a33f0..2062faaca 100644
--- a/content/product/virtual_machines_operation/multi-vm_workflows/appflow_use_cli.md
+++ b/content/product/virtual_machines_operation/multi-vm_workflows/appflow_use_cli.md
@@ -19,7 +19,7 @@ OneFlow allows users and administrators to define, execute, and manage multi-tie
The following diagram represents a multi-tier application. Each node represents a Role and its cardinality (the number of VMs that will be deployed). The arrows indicate the deployment dependencies: each Role’s VMs are deployed only when all its parent’s VMs are running.
-
+{{< image path="/images/service_sample.svg" alt="Multi-tier application with deployment dependencies" align="center" width="50%" pb="20px" >}}
This Service can be represented with the following JSON template:
@@ -1047,11 +1047,11 @@ From any VM, use the `PUT ${ONEGATE_ENDPOINT}/vm` action to store any informatio
You can read more details in the [OneGate API documentation]({{% relref "onegate_usage#onegate-usage" %}}).
-### Network Mapping & Floating IPs
+### Network Mapping and Floating IPs
Network mapping in OneFlow is facilitated through the use of Virtual Router Roles, which enable efficient management of network resources and floating IPs within your cloud environment.
-
+{{< image path="/images/oneflow-network-map.svg" alt="OneFlow Network Mapping" align="center" width="50%" pb="20px" >}}
**Configuring the Service Template**
diff --git a/content/product/virtual_machines_operation/multi-vm_workflows/onegate_usage.md b/content/product/virtual_machines_operation/multi-vm_workflows/onegate_usage.md
index 15547add4..cdb1a3028 100644
--- a/content/product/virtual_machines_operation/multi-vm_workflows/onegate_usage.md
+++ b/content/product/virtual_machines_operation/multi-vm_workflows/onegate_usage.md
@@ -23,7 +23,7 @@ For Virtual Machines that are part of a Multi-VM Application ([OneFlow Service](
OneGate is a server that listens to http connections from the Virtual Machines. OpenNebula assigns an individual token to each VM instance and Applications running inside the VM use this token to interact with the OneGate API. This token is generated using VM information and signed with the owner User template attribute `TOKEN_PASSWORD`. This password can be changed by updating the User template, but tokens from existing VMs will not work anymore.
-
+{{< image path="/images/onegate_arch.svg" alt="OneGate Architecture" align="center" width="80%" pb="20px" >}}
## OneGate Usage