docs(gen): docs content review (#4595)

bene2k1 · jcirinosclwy · web-flow · commit 46097729e7ba · 2025-03-11T16:23:48.000+01:00
* docs(gen): docs content review

* Update pages/dedibox-hardware/concepts.mdx

* fix(ins): fix typo

* Update pages/instances/troubleshooting/fix-unreachable-ipv6-rhel-based-instance.mdx

Co-authored-by: Jessica &lt;113192637+jcirinosclwy@users.noreply.github.com&gt;

* Apply suggestions from code review

Co-authored-by: Jessica &lt;113192637+jcirinosclwy@users.noreply.github.com&gt;

---------

Co-authored-by: Jessica &lt;113192637+jcirinosclwy@users.noreply.github.com&gt;
diff --git a/faq/apple-silicon.mdx b/faq/apple-silicon.mdx
@@ -5,7 +5,7 @@ meta:
 content:
   h1: Apple silicon
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
 category: bare-metal
 productIcon: AppleSiliconProductIcon
 ---
diff --git a/pages/dedibox-account/how-to/resolve-abuse.mdx b/pages/dedibox-account/how-to/resolve-abuse.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains how to resolve Abuse tickets.
 tags: resolve abuse complaint ticket dedibox-console
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
   posted: 2020-03-12
 categories:
   - account
diff --git a/pages/dedibox-hardware/concepts.mdx b/pages/dedibox-hardware/concepts.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains all the concepts related to your servers Hardware
 tags: dedibox hardware cpu hdd nvme ssd raid raid 0 raid-0 raid 1 raid-1 raid-5
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
 categories:
   - dedibox-servers
 ---
@@ -20,7 +20,7 @@ A Central Processing Unit (CPU) is the computer's main processor. The CPU execut
 
 A Hard disk drive (HDD) uses rotating magnetic disks to store data. HDDs provide larger storage capacity but slower read/write speed compared to SSDs. They are perfect for storing large volumes of data.
 
-## NVMe
+## NVMe disk
 
 NVM Express (NVMe) disks are SSDs that use the PCI Express bus for communication with the host.
 
diff --git a/pages/dedibox-ipv6/concepts.mdx b/pages/dedibox-ipv6/concepts.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains all the concepts related to IPv6 on
 tags: dedibox ipv6 duid dhcpv6 ipv4 slaac stateful stateless dhcp
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
 categories:
   - dedibox-network
 ---
diff --git a/pages/dedibox-kvm-over-ip/concepts.mdx b/pages/dedibox-kvm-over-ip/concepts.mdx
@@ -9,7 +9,7 @@ tags: kvm iso-file idrac ilo iso
 categories:
   - dedibox-servers
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
 ---
 
 ## KVM Over IP
diff --git a/pages/dedibox-kvm-over-ip/quickstart.mdx b/pages/dedibox-kvm-over-ip/quickstart.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: KVM over IP Quickstart
 tags: dedibox kvm over-ip
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
 categories:
   - dedibox-servers
 ---
diff --git a/pages/dedibox/reference-content/basic-linux-commands.mdx b/pages/dedibox/reference-content/basic-linux-commands.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: Learn how to use some basic Linux/Unix commands
 tags: dedibox linux unix command
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
 categories:
   - dedibox-servers
 ---
diff --git a/pages/generative-apis/api-cli/using-chat-api.mdx b/pages/generative-apis/api-cli/using-chat-api.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains how to use the Chat API to query models
 tags: generative-apis ai-data chat-api
 dates:
-  validation: 2024-09-03
+  validation: 2025-03-11
   posted: 2024-09-03
 ---
 
diff --git a/pages/generative-apis/api-cli/using-embeddings-api.mdx b/pages/generative-apis/api-cli/using-embeddings-api.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains how to use the Embeddings API
 tags: generative-apis ai-data embeddings-api
 dates:
-  validation: 2024-09-03
+  validation: 2025-03-11
   posted: 2024-09-03
 ---
 
diff --git a/pages/generative-apis/api-cli/using-models-api.mdx b/pages/generative-apis/api-cli/using-models-api.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains how to use the Models API
 tags: generative-apis ai-data embeddings-api
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
   posted: 2024-09-02
 ---
 
diff --git a/pages/generative-apis/reference-content/model-lifecycle.mdx b/pages/generative-apis/reference-content/model-lifecycle.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains how each status affects model usage and updates.
 tags: generative-apis ai-data model-lifecyle
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
   posted: 2024-09-02
 ---
 
diff --git a/pages/gpu/how-to/create-manage-gpu-instance.mdx b/pages/gpu/how-to/create-manage-gpu-instance.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains how to create and manage a GPU Instance
 tags: gpu-instance gpu instance
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
   posted: 2022-03-25
 categories:
   - compute
@@ -34,17 +34,17 @@ When you have completed your calculations using the GPU Instance, [deletion can
 3. Follow these steps to configure your GPU Instance:
     - **Availability Zone**: Choose the geographical region, represented by the Availability Zone, where your Instance will be deployed.
     - **Instance Type (GPU)**: Select the desired GPU Instance type, considering factors such as processing power, memory, storage options, and bandwidth. Refer to our guide on [choosing the right GPU Instance type](/gpu/reference-content/choosing-gpu-instance-type/) for more information.
-    - **Image**: Pick an operating system image suitable for your GPU Instance. For example, select **Ubuntu Jammy GPU OS 12**, which comes with preinstalled NVIDIA drivers and an NVIDIA Docker environment. You have the flexibility to customize your working environment using Docker with our provided Docker images or your own containers.
+    - **Image**: Pick an operating system image suitable for your GPU Instance. For example, select **Ubuntu Jammy GPU OS 12**, which comes with preinstalled Nvidia drivers and an Nvidia Docker environment. You can customize your working environment using Docker with our provided Docker images or your own containers.
+    - **Instance name and tags**: Assign a name to your Instance for easy identification. You can also add tags to organize your Instances efficiently.
     - **Volumes**: Optionally, add storage volumes for your Instance. You can adjust settings such as Block and Local Storage volumes according to your requirements.
         <Message type="note">
           * The recommended minimum volume size for GPU OS images is 125 GB.
           * If your GPU Instance supports scratch storage, the scratch volume displays but can not be edited. [Learn more about scratch storage.](/gpu/how-to/use-scratch-storage-h100-instances/)
         </Message>
-    - **Network Configuration**: Choose between a routed public IP or a NAT public IP for your Instance. We recommend using a routed public IP. You can allocate IPv4 and IPv6 addresses as needed, with a maximum of 5 IPs per Instance.
-    - **Instance Name and Tags**: Assign a name to your Instance for easy identification. You can also add tags to organize your Instances efficiently.
-    - **Advanced Options**: Configure `cloud-init` settings if required, or leave them at default values.
-    - **SSH Keys**: Verify the SSH keys that will grant you access to your Instance.
-    - **Estimated Cost**: Review the estimated cost of your GPU Instance based on the selected specifications.
+    - **Network configuration**: You can allocate routed IPv4 and IPv6 addresses as needed, with a maximum of 5 IPs per Instance.
+    - **Cloud-init**: Configure `cloud-init` settings if required, or leave them at default values.
+    - **SSH keys**: Verify the SSH keys that will grant you access to your Instance.
+    - **Estimated cost**: Review the estimated cost of your GPU Instance based on the selected specifications.
 4. Once you have completed the configuration, click on **Create Instance** to initiate the creation process. You will receive a notification once the GPU Instance is ready for use.
 
 ## How to connect to a GPU Instance
diff --git a/pages/gpu/quickstart.mdx b/pages/gpu/quickstart.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page shows you how to get started with Scaleway GPU Instances.
 tags: instance gpu-instance
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
   posted: 2022-03-25
 categories:
   - compute
@@ -27,14 +27,14 @@ In addition to this, GPU Instances have all the features of our regular Instance
     - **Availability Zone**: Choose the geographical region, represented by the Availability Zone, where your Instance will be deployed.
     - **Instance Type (GPU)**: Select the desired GPU Instance type, considering factors such as processing power, memory, storage options, and bandwidth. Refer to our guide on [choosing the right GPU Instance type](/gpu/reference-content/choosing-gpu-instance-type/) for more information.
     - **Image**: Pick an operating system image suitable for your GPU Instance. For example, select **Ubuntu Jammy GPU OS 12**, which comes with preinstalled Nvidia drivers and an Nvidia Docker environment. You can customize your working environment using Docker with our provided Docker images or your own containers.
+    - **Instance name and tags**: Assign a name to your Instance for easy identification. You can also add tags to organize your Instances efficiently.
     - **Volumes**: Optionally, add storage volumes for your Instance. You can adjust settings such as Block and Local Storage volumes according to your requirements.
         <Message type="note">
           * The recommended minimum volume size for GPU OS images is 125 GB.
           * If your GPU Instance supports scratch storage, the scratch volume displays but can not be edited. [Learn more about scratch storage.](/gpu/how-to/use-scratch-storage-h100-instances/)
         </Message>
-    - **Network configuration**: Choose between a routed public IP or a NAT public IP for your Instance. We recommend using a routed public IP. You can allocate IPv4 and IPv6 addresses as needed, with a maximum of 5 IPs per Instance.
-    - **Instance name and tags**: Assign a name to your Instance for easy identification. You can also add tags to organize your Instances efficiently.
-    - **Advanced options**: Configure `cloud-init` settings if required, or leave them at default values.
+    - **Network configuration**: You can allocate routed IPv4 and IPv6 addresses as needed, with a maximum of 5 IPs per Instance.
+    - **Cloud-init**: Configure `cloud-init` settings if required, or leave them at default values.
     - **SSH keys**: Verify the SSH keys that will grant you access to your Instance.
     - **Estimated cost**: Review the estimated cost of your GPU Instance based on the selected specifications.
 4. Once you have completed the configuration, click on **Create Instance** to initiate the creation process. You will receive a notification once the GPU Instance is ready for use.
diff --git a/pages/instances/api-cli/increasing-volume-size.mdx b/pages/instances/api-cli/increasing-volume-size.mdx
@@ -7,13 +7,17 @@ content:
   paragraph: This page explains how to increase a Block Storage volume
 tags: increase expand increment raise storage volume block
 dates:
-  validation: 2024-08-26
+  validation: 2025-03-11
   posted: 2020-01-10
 categories:
   - block-storage
   - storage
 ---
 
+<Message type="important">
+  Management of Block Storage volumes via the Instances API is deprecated. We recommend migrating existing volumes to the Block Storage API for continued support and improved functionality. For step-by-step instructions on migrating your volumes, refer to our [How to migrate existing volumes and snapshots to Scaleway's new Block Storage management](/instances/how-to/migrate-volumes-snapshots-to-sbs/).
+</Message>
+
 The Instances API allows you to interact with Block Storage volumes programmatically through API calls. To increase the size of a volume using the Block Storage API, refer to the [dedicated documentation](/block-storage/api-cli/increasing-volume-size/).
 
 <Macro id="requirements" />
diff --git a/pages/instances/how-to/create-a-backup.mdx b/pages/instances/how-to/create-a-backup.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains how to create an image of your Instance
 tags: instance image backup
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
   posted: 2021-05-26
 categories:
   - compute
diff --git a/pages/instances/how-to/power-off-instance.mdx b/pages/instances/how-to/power-off-instance.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains how to power off a Scaleway Instance.
 tags: power off power-off instance
 dates:
-  validation: 2024-08-26
+  validation: 2025-03-11
   posted: 2021-05-26
 categories:
   - compute
diff --git a/pages/instances/troubleshooting/fix-unreachable-ipv6-rhel-based-instance.mdx b/pages/instances/troubleshooting/fix-unreachable-ipv6-rhel-based-instance.mdx
@@ -7,78 +7,84 @@ content:
   paragraph: This page helps recover or avoid unreachable IPv6 Instances after transitioning to routed IP
 tags: centos-stream rockylinux almalinux network-manager ipv6 routed ip
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
   posted: 2023-11-16
 categories:
   - compute
 ---
 
-RHEL-based Instances created before November 15 2023 require a NetworkManager configuration that enables correct IPv6 configuration, after a transition to routed IP is performed. If your Instance is configured only with an IPv6 address, it will become unreachable after the migration. It is important to add the NetworkManager configuration so IPv6 configuration remains correct.<br />
+## Problem
+
+RHEL-based Instances created before November 15 2023 require a NetworkManager configuration that enables correct IPv6 configuration, after a transition to routed IP is performed. If your Instance is configured only with an IPv6 address, it will become unreachable after the migration. It is important to add the NetworkManager configuration so IPv6 configuration remains correct. 
 
 The affected O/S distributions are:
 
 - CentOS Stream versions 8 and 9
 - RockyLinux versions 8 and 9
 - AlmaLinux versions 8 and 9
-- Fedora versions 37 and 38
+- Fedora versions 37 and 38.
 
 <Message type="note">
-  CentOS 7.9 is not concerned by this issue as it does not support routed IP.
+  CentOS 7.9 is not concerned by this issue, as it does not support routed IP.
 </Message>
 
-<Message type="note">
-  This guide addresses specific issues related to RHEL-based Instances after transitioning to routed IP. For general information on routed IPs and migration procedures, refer to our [main migration guide](/instances/how-to/migrate-routed-ips/) and the [related FAQ](/faq/instances/#are-there-any-limitations-on-ip-autoconfiguration-with-the-routed-ip-feature).
-</Message>
+This guide addresses specific issues related to RHEL-based Instances after transitioning to routed IP.
+For general information on routed IPs and migration procedures, refer to our [main migration guide](/instances/how-to/migrate-routed-ips/) and the [related FAQ](/faq/instances/#are-there-any-limitations-on-ip-autoconfiguration-with-the-routed-ip-feature).
+
+## Cause
+
+This issue is caused by a missing NetworkManager configuration for IPv6 address generation mode (`ipv6.addr-gen-mode=0`) on RHEL-based Instances.
+
+## Possible solution
+
+There are two scenarios to consider, depending on whether your Instance has been migrated to routed IP or not.
 
-## Your Instance has not been migrated to routed IP yet
+### Your Instance has not been migrated to routed IP yet
 
 Connect to your Instance and execute the following command as `root` user to add the required NetworkManager option:
-```
+```bash
 cat << EOF > /etc/NetworkManager/conf.d/00-scaleway.conf
 [connection]
 # The value 0 stands for eui64 -- see nm-settings-nmcli(5)
 ipv6.addr-gen-mode=0
 EOF
 ```
+### Your Instance has been moved to routed IP
 
-## Your Instance has been moved to routed IP
-
-If your Instance has been moved to routed IP and you have IPv4 connectivity, add the NetworkManager configuration as outlined in the previous section. After the next reboot, you will recover IPv6 connectivity while IPv4 configuration will remain untouched
-
-### You only have IPv6 configured so you cannot connect to the Instance anymore
+If your Instance has been moved to routed IP and you have IPv4 connectivity, add the NetworkManager configuration as outlined in the previous section. After the next reboot, you will recover IPv6 connectivity while IPv4 configuration will remain untouched.  
 
-  <Message type="important">
-    Two reboots of your Instance will be required in order to recover IPv6 connectivity.
-  </Message>
+#### You only have IPv6 configured so you cannot connect to the Instance anymore
 
-If you are in this situation, you need to temporarily add an IPv4 address to connect to your Instance in order to add the NetworkManager configuration.
+Two reboots of your Instance will be required in order to recover IPv6 connectivity. If you are in this situation, you need to temporarily add an IPv4 address to connect to your Instance in order to add the NetworkManager configuration.
 
-```
+```bash
 scw instance server list
 ID            NAME    TYPE    STATE     ZONE      PUBLIC IP           PRIVATE IP  TAGS  IMAGE NAME          ROUTED
 {Instance_ID} rocky8  DEV1-S  running   fr-par-2  2001:bc8:1210:26a:dc00:ff:fe23:ab83  - [] RockyLinux 8     true
-
 scw instance ip create type=routed_ipv4 server={Instance_ID}
 scw instance server reboot {Instance_ID}
-
 ```
 Once the reboot is completed, list your IP addresses and identify the IPv4 address attached to your Instance:
-```
+
+```bash
 $ scw instance ip list
 ID                 ADDRESS         PREFIX                  TYPE         REVERSE  PROJECT       SERVER ID     SERVER NAME  TAGS  ZONE
 {IPv6_address_ID}  -               2001:bc8:1210:26a::/64  routed_ipv6  -        {project id}  {project id}  rocky8       []    fr-par-2
 {IPv4_address_ID}  51.159.143.128  -                       routed_ipv4  -        {project id}  {project id}  rocky8       []    fr-par-2
 ```
 You can now connect to your Instance with the IPv4 address to make the NetworkManager configuration change:
-```
+
+```bash
 ssh root@51.159.143.128
 cat << EOF > /etc/NetworkManager/conf.d/00-scaleway.conf
 [connection]
 ipv6.addr-gen-mode=0
 EOF
 ```
+
 Once modified, reset your Instance to its prior configuration. It is necessary to first detach the IPv4 address before attaching the IPv6 address.
-```
+
+```bash
 scw instance server standby {Instance_ID}
 scw instance server update {Instance_ID} ip=none
 scw instance server update {Instance_ID} ip={IPv6_address_ID}
@@ -87,11 +93,18 @@ scw instance ip delete {IPv4_address_ID}
 ```
 
 You can now connect using your IPv6 address:
-```
+
+```bash
 ssh root@2001:bc8:1210:26a:dc00:ff:fe23:ab83
 Warning: Permanently added '2001:bc8:1210:26a:dc00:ff:fe23:ab83' (ED25519) to the list of known hosts.
 Activate the web console with: systemctl enable --now cockpit.socket
-
  Last login: Wed Nov 15 16:53:09 2023 from 51.159.46.153
  [root@rocky8 ~]#
-```
+```
+
+## Going further
+For general information on routed IPs and migration procedures, refer to our [main migration guide](/instances/how-to/migrate-routed-ips/) and the [related FAQ](/faq/instances/#are-there-any-limitations-on-ip-autoconfiguration-with-the-routed-ip-feature). If you still encounter issues, please provide the following information when creating a support ticket:
+- Instance ID
+- Operating System version
+- Current IP configuration
+- Steps taken to resolve the issue
diff --git a/pages/kubernetes/how-to/access-audit-logs.mdx b/pages/kubernetes/how-to/access-audit-logs.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains how to access the dashboard of your Kubernetes cluster
 tags: kubernetes kubernetes-kapsule kapsule kosmos cluster audit logs
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
   posted: 2024-01-24
 categories:
   - kubernetes
diff --git a/pages/kubernetes/how-to/deploy-x86-arm-images.mdx b/pages/kubernetes/how-to/deploy-x86-arm-images.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: This page explains how to deploy both x86 and ARM images in Kubernetes
 tags: kubernetes kapsule arm x86
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
   posted: 2024-02-29
 categories:
   - kubernetes
diff --git a/pages/kubernetes/troubleshooting/containers-not-starting-arm-instances.mdx b/pages/kubernetes/troubleshooting/containers-not-starting-arm-instances.mdx
@@ -7,28 +7,30 @@ content:
   paragraph: This page helps you troubleshoot issues related to containers not starting on ARM Instances
 tags: kapsule arm x86 crashloopbackoff
 dates:
-  validation: 2024-09-02
+  validation: 2025-03-11
   posted: 2024-02-28
 categories:
   - kubernetes
 ---
 
+## Problem
 Containers failing to start on ARM nodes can often be attributed to architecture mismatches. This occurs when container images designed for x86 architecture are deployed on ARM-based nodes.
 
+## Cause
 The binary instructions in the x86 image are incompatible with ARM processors, causing the kernel on the ARM node to encounter illegal or unknown instructions, resulting in errors.
 
 The most common symptom of this issue is the occurrence of `CrashLoopBackOff` errors in Kubernetes.
 
-## Inspecting container image architecture
+## Possible solutions
+
+### Inspecting container image architecture
 
 To inspect the architecture of container images, you can use the following steps:
 
 1. Pull the container image from the registry using `docker pull`.
 2. Extract the image using `docker save` or similar tools.
 3. Within the extracted files, locate the image manifest file (usually named `manifest.json`). Open this file and look for the `architecture` field to determine the architecture the image is built for.
 
-## Possible solutions
-
 ### Rebuilding ARM images
 
 If you have control over the container image source, consider rebuilding the image specifically for the ARM architecture.
