M #- Product: migrated to SVG

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).
 
-![><](/images/overview_customized-cluster.png)
-
-<!-- overview_customized-cluster.png -->
+{{< 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
 

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.
 
-![HTTP marketplace overview](/images/market_http.png)
+{{< 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:
 

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.
 
-![image0](/images/collector.png)
+{{< 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.
 

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:
 
-![scheduler_architecture](/images/scheduler_architecture.png)
+{{< image path="/images/scheduler_architecture.svg" alt="Scheduler Architecture" align="center" width="70%" pb="20px" >}}
 
 Main components:
 

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](/images/backup_veeam_architecture.png)
+{{< image path="/images/backup_veeam_architecture.svg" alt="Architecture of the OpenNebula-Veeam Backup Integration" align="center" width="70%" pb="20px" >}}
 
 ## Backup Server Requirements
 

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/<id>`) 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.
 
-![image0](/images/fs_lvm_datastore.svg)
+{{< 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 >}}
 

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.
 
-![><](/images/fs_ssh.png)
+{{< 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.
 
-![><](/images/local_ds_cache.png)
+{{< 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
 

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.
 
-![image1](/images/fs_shared.png)
+{{< image path="/images/fs_shared.svg" alt="VM disks linked in the System Datastore directory" align="center" width="60%" pb="20px" >}}
+

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" %}}).
 
-![image0](/images/datastoreoverview.png)
+{{< image path="/images/datastoreoverview.svg" alt="Overview of Storage Design based on Datastores" align="center" width="50%" pb="20px" >}}
 
 ### Image Datastores
 

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:
 
-![><](/images/one_scalability.png)
+{{< 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.
 

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.
 
-![hook-subsystem](/images/hooks-subsystem-architecture.png)
+{{< 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.
 

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.
 
-![image0](/images/service_sample.png)
+{{< 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.
 
-![oneflow-network-mapping](/images/oneflow-network-map.png)
+{{< image path="/images/oneflow-network-map.svg" alt="OneFlow Network Mapping" align="center" width="50%" pb="20px" >}}
 
 **Configuring the Service Template**
 

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.
 
-![onegate_arch](/images/onegate_arch.png)
+{{< image path="/images/onegate_arch.svg" alt="OneGate Architecture" align="center" width="80%" pb="20px" >}}
 
 ## OneGate Usage