You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Cloud Deployment. Changes on sudo command, general wording, and copy/paste buttons.
- LLM Inference. Changes on wording, accessing the VM to show progress on deployment.
- AI-ready Kubernetes. Wording and minor fixes.
Co-authored-by: Carlos Moral Rubio <carlos@MacBook-Pro-de-Carlos.local>
Co-authored-by: Aleix Ramírez Baena <aramirez@opennebula.io>
(cherry picked from commit b30b477)
Copy file name to clipboardExpand all lines: content/solutions/deployment_blueprints/ai-ready_opennebula/ai_ready_k8s.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -329,7 +329,8 @@ ID USER GROUP NAME STAT CPU MEM HOS
329
329
330
330
#### Connecting to the Workload Cluster Kubernetes API Locally
331
331
332
-
To establish a local connection to the Workload Cluster Kubernetes API, you will need to export the following environment variables. The `$VROUTER_IP` will contain the public IP address of the vRouter instance, and the `$CONTROL_PLANE_IP` will contain the IP address of the workload cluster control plane instance. Note that the virtual machines change on each deploy, so change the name of the vRouter and control plane instance appropriately in the following code block:
332
+
To establish a local connection to the Workload Cluster Kubernetes API, you will need to export the following environment variables. The `$VROUTER_IP` will contain the public IP address of the vRouter instance, and the `$CONTROL_PLANE_IP` will contain the IP address of the workload cluster control plane instance. Here, we will connect directly to the Kubernetes cluster from the OpenNebula frontend, to make things simpler.
333
+
Note that the virtual machines change on each deploy, so change the name of the vRouter and control plane instance appropriately in the following code block:
Copy file name to clipboardExpand all lines: content/solutions/deployment_blueprints/ai-ready_opennebula/cd_cloud.md
+17-11Lines changed: 17 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,10 +6,11 @@ weight: 3
6
6
---
7
7
8
8
<aid="cd_cloud"></a>
9
+
This document describes the procedure to deploy an AI-ready OpenNebula cloud using OneDeploy on a single [Scaleway Elastic Metal](https://www.scaleway.com/en/elastic-metal/) bare-metal server equipped with GPUs.
9
10
10
-
Here you have a practical guide to deploy an AI-ready OpenNebula cloud using OneDeploy on a single [Scaleway Elastic Metal](https://www.scaleway.com/en/elastic-metal/) instance equipped with GPUs. This setup is ideal for demonstrations, proofs-of-concept (PoCs), or for quickly trying out the solution without the need for a complex physical infrastructure.
11
+
The architecture is a converged OpenNebula installation, where the frontend services and KVM hypervisor run on the same physical host. This approach is ideal for demonstrations, proofs-of-concept (PoCs), or for quickly trying out the solution without the need for a complex physical infrastructure.
11
12
12
-
The outlined procedure is based on an instance with NVIDIA L40S GPUs as an example. A converged OpenNebula cloud, including frontend and KVM node, is deployed on the same bare metal server.
13
+
The outlined procedure is based on an instance with NVIDIA L40S GPUs as an example.
13
14
14
15
## Prerequisites
15
16
@@ -63,20 +64,25 @@ If the directory is not empty it means that IOMMU is active, which is a prerequi
63
64
64
65
### Server Pre-configuration
65
66
66
-
These steps prepare the server for the OneDeploy tool, which runs as the `root`user.
67
+
The following steps prepare the server to run OneDeploy, which operates with `root`privileges.
67
68
68
-
1.Enable Local Root SSH Access:
69
-
Generate an SSH key pair for the `root` user and authorize it for local connections. This allows Ansible to connect to `127.0.0.1` as `root`.
69
+
1.Obtain Root Privileges:
70
+
OneDeploy installs software and modifies system-level configuration files. To perform these actions, open a `root` shell.
To provide network connectivity to the VMs, create a virtual bridge with NAT. This allows VMs to access the internet through the server's public network interface.
78
84
79
-
2.1 Create the Netplan configuration file for the bridge:
85
+
3.1 Create the Netplan configuration file for the bridge:
80
86
```shell
81
87
tee /etc/netplan/60-bridge.yaml > /dev/null << 'EOF'
82
88
network:
@@ -94,8 +100,8 @@ These steps prepare the server for the OneDeploy tool, which runs as the `root`
94
100
EOF
95
101
```
96
102
97
-
2.2 Apply the network configuration and enable IP forwarding. Replace `enp129s0f0np0` with your server's main network interface if it is different.
98
-
```default
103
+
3.2 Apply the network configuration and enable IP forwarding. Replace `enp129s0f0np0` with your server's main network interface if it is different.
Copy file name to clipboardExpand all lines: content/solutions/deployment_blueprints/ai-ready_opennebula/llm_inference_certification.md
+10-1Lines changed: 10 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -60,8 +60,17 @@ To deploy the vLLM appliance for benchmarking, follow these steps:
60
60
onetemplate instantiate vllm --name vllm
61
61
```
62
62
63
-
4. Wait until the vLLM engine has loaded the model and the application is served. To confirm progress, access the VM via SSH and check the logs located in`/var/log/one-appliance/vllm.log`. You should see an output similar to this:
63
+
4. Wait until the vLLM engine has loaded the model and the application is served. To confirm progress, access the VM via SSH and check the logs located in`/var/log/one-appliance/vllm.log`.
64
+
65
+
4.1 To access the VM, run the following command:
64
66
```shell
67
+
onevm ssh vllm
68
+
```
69
+
You can also list all available VMs by running `onevm list`.
70
+
71
+
4.2 Once inside the VM, check the logs in`/var/log/one-appliance/vllm.log`. You should see an output similar to this:
72
+
73
+
```base
65
74
[...]
66
75
67
76
(APIServer pid=2480) INFO 11-26 11:00:33 [api_server.py:1971] Starting vLLM API server 0 on http://0.0.0.0:8000
0 commit comments