Skip to content

Commit 619a52e

Browse files
cmoralopennebulaCarlos Moral Rubioaleixrm
authored andcommitted
B #-: Fix on AI blueprints documentation (#494)
- 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)
1 parent f943d4f commit 619a52e

File tree

3 files changed

+29
-13
lines changed

3 files changed

+29
-13
lines changed

content/solutions/deployment_blueprints/ai-ready_opennebula/ai_ready_k8s.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -329,7 +329,8 @@ ID USER GROUP NAME STAT CPU MEM HOS
329329
330330
#### Connecting to the Workload Cluster Kubernetes API Locally
331331
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:
333334
334335
```shell
335336
export VROUTER_VM_NAME=<changeme>

content/solutions/deployment_blueprints/ai-ready_opennebula/cd_cloud.md

Lines changed: 17 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -6,10 +6,11 @@ weight: 3
66
---
77

88
<a id="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.
910

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.
1112

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.
1314

1415
## Prerequisites
1516

@@ -63,20 +64,25 @@ If the directory is not empty it means that IOMMU is active, which is a prerequi
6364

6465
### Server Pre-configuration
6566

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.
6768

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.
7071
```shell
71-
sudo su
72-
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N "" -q
72+
sudo -i
73+
```
74+
75+
2. Configure Local Root SSH Access:
76+
Generate an SSH key pair for `root` and authorize it for local connections. This allows Ansible to connect to `127.0.0.1` as `root`.
77+
```shell
78+
ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -q
7379
cat /root/.ssh/id_ed25519.pub >> /root/.ssh/authorized_keys
7480
```
7581

76-
2. Create a Virtual Network Bridge:
82+
3. Create a Virtual Network Bridge:
7783
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.
7884
79-
2.1 Create the Netplan configuration file for the bridge:
85+
3.1 Create the Netplan configuration file for the bridge:
8086
```shell
8187
tee /etc/netplan/60-bridge.yaml > /dev/null << 'EOF'
8288
network:
@@ -94,8 +100,8 @@ These steps prepare the server for the OneDeploy tool, which runs as the `root`
94100
EOF
95101
```
96102
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.
104+
```shell
99105
netplan apply
100106
sysctl -w net.ipv4.ip_forward=1
101107
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o enp129s0f0np0 -j MASQUERADE

content/solutions/deployment_blueprints/ai-ready_opennebula/llm_inference_certification.md

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -60,8 +60,17 @@ To deploy the vLLM appliance for benchmarking, follow these steps:
6060
onetemplate instantiate vllm --name vllm
6161
```
6262

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:
6466
```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
6574
[...]
6675
6776
(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

Comments
 (0)