Skip to content

Removed the extra $ character from the commands and also corrected a … #187

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
akashraj4261 merged 1 commit into from
Feb 24, 2026
Merged

Removed the extra $ character from the commands and also corrected a … #187

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions versions/v1.5/modules/en/pages/virtual-machines/vm-images/upload-image.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ To import virtual machine images in the *Images* page, enter a URL that can be a
+
[NOTE]
====
* The image name will be auto-filled using the file name in the URL address. You can customize the image name at any time.
* The image name is auto-filled using the file name in the URL address. You can customize the image name at any time.
* Avoid using a daily build URL (for example, the https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img[Ubuntu Jammy daily build]). When all replicas of a Longhorn backing image are lost, Longhorn attempts to download the file again for self-healing purposes. Using a daily build URL is problematic because the URL itself changes, causing a checksum mismatch and a conflict that results in lost replicas.
====
+
Expand Down Expand Up @@ -60,7 +60,7 @@ resource "harvester_image" "opensuse154" {

== Upload Images via Local File

Currently, qcow2, raw, and ISO images are supported.
Currently, qcow2, raw and ISO images are supported.

[NOTE]
====
Expand All @@ -85,7 +85,7 @@ If {rancher-product-name} is deployed on an RKE2 cluster, perform the following
+
[,sh]
----
$ kubectl -n cattle-system edit ingress rancher
kubectl -n cattle-system edit ingress rancher
----

. Specify a value for `nginx.ingress.kubernetes.io/proxy-body-size`.
Expand All @@ -110,7 +110,7 @@ If {rancher-product-name} is deployed on an RKE2 cluster, perform the following
+
[,sh]
----
$ kubectl -n cattle-system edit ingress rancher
kubectl -n cattle-system edit ingress rancher
----

. Turn off `nginx.ingress.kubernetes.io/proxy-request-buffering`.
Expand All @@ -125,7 +125,7 @@ image:img-ingress-request-proxy-buffering.png[]

Starting with *v1.5.5*, Longhorn https://github.com/longhorn/backing-image-manager/pull/153[compresses backing images for downloading]. If you attempt to upload a compressed backing image, {harvester-product-name} rejects the attempt and displays the message *Upload failed: the uploaded file size xxxx should be a multiple of 512 bytes since Longhorn uses directIO by default* because the compressed data violates Longhorn's data alignment.

Before uploading, decompress backing images using the command `$ gzip -d <file name>`.
Before uploading, decompress backing images using the command `gzip -d <file name>`.

== Create Images via Volumes

Expand All @@ -139,17 +139,17 @@ When creating an image, you can select a xref:/storage/storageclass.adoc[Storage

[NOTE]
====
The image will not use the `StorageClass` selected here directly. It's just a `StorageClass` template.
The image does not use the `StorageClass` selected here directly. It is just a `StorageClass` template.

Instead, it will create a special StorageClass under the hood with a prefix name of `longhorn-`. This is automatically done by the {harvester-product-name} backend, but it will inherit the parameters from the StorageClass you have selected.
Instead, it creates a special StorageClass under the hood with a prefix name of `longhorn-`. This is automatically done by the {harvester-product-name} back-end, but it inherits the parameters from the StorageClass you have selected.
====

image::image-storageclass.png[]

== Image Labels

You can add labels to the image, which will help identify the OS type more accurately. Also, you can add any custom labels for filtering if needed.
You can add labels to the image, which helps identify the OS type accurately. Also, you can add any custom labels for filtering if needed.

If your image name or URL contains any valid information, the UI will automatically recognize the OS type and image category for you. If not, you can also manually specify those corresponding labels on the UI.
If your image name or URL contains any valid information, the UI automatically recognizes the OS type and image category for you. If not, you can also manually specify those corresponding labels on the UI.

image::image-labels.png[]
16 changes: 8 additions & 8 deletions versions/v1.6/modules/en/pages/virtual-machines/vm-images/upload-image.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ To import virtual machine images in the *Images* page, enter a URL that can be a
+
[NOTE]
====
* The image name will be auto-filled using the file name in the URL address. You can customize the image name at any time.
* The image name is auto-filled using the file name in the URL address. You can customize the image name at any time.
* Avoid using a daily build URL (for example, the https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img[Ubuntu Jammy daily build]). When all replicas of a Longhorn backing image are lost, Longhorn attempts to download the file again for self-healing purposes. Using a daily build URL is problematic because the URL itself changes, causing a checksum mismatch and a conflict that results in lost replicas.
====
+
Expand Down Expand Up @@ -90,7 +90,7 @@ If {rancher-product-name} is deployed on an RKE2 cluster, perform the following
+
[,sh]
----
$ kubectl -n cattle-system edit ingress rancher
kubectl -n cattle-system edit ingress rancher
----

. Specify a value for `nginx.ingress.kubernetes.io/proxy-body-size`.
Expand All @@ -115,7 +115,7 @@ If {rancher-product-name} is deployed on an RKE2 cluster, perform the following
+
[,sh]
----
$ kubectl -n cattle-system edit ingress rancher
kubectl -n cattle-system edit ingress rancher
----

. Turn off `nginx.ingress.kubernetes.io/proxy-request-buffering`.
Expand All @@ -130,7 +130,7 @@ image:img-ingress-request-proxy-buffering.png[]

Starting with *v1.5.5*, Longhorn https://github.com/longhorn/backing-image-manager/pull/153[compresses backing images for downloading]. If you attempt to upload a compressed backing image, {harvester-product-name} rejects the attempt and displays the message *Upload failed: the uploaded file size xxxx should be a multiple of 512 bytes since Longhorn uses directIO by default* because the compressed data violates Longhorn's data alignment.

Before uploading, decompress backing images using the command `$ gzip -d <file name>`.
Before uploading, decompress backing images using the command `gzip -d <file name>`.

== Create Images via Volumes

Expand All @@ -144,17 +144,17 @@ When creating an image, you can select a xref:/storage/storageclass.adoc[Storage

[NOTE]
====
The image will not use the `StorageClass` selected here directly. It's just a `StorageClass` template.
The image does not use the `StorageClass` selected here directly. It is just a `StorageClass` template.

Instead, it will create a special StorageClass under the hood with a prefix name of `longhorn-`. This is automatically done by the {harvester-product-name} backend, but it will inherit the parameters from the StorageClass you have selected.
Instead, it creates a special StorageClass under the hood with a prefix name of `longhorn-`. This is automatically done by the {harvester-product-name} back-end, but it inherits the parameters from the StorageClass you have selected.
====

image::image-storageclass.png[]

== Image Labels

You can add labels to the image, which will help identify the OS type more accurately. Also, you can add any custom labels for filtering if needed.
You can add labels to the image, which helps identify the OS type accurately. Also, you can add any custom labels for filtering if needed.

If your image name or URL contains any valid information, the UI will automatically recognize the OS type and image category for you. If not, you can also manually specify those corresponding labels on the UI.
If your image name or URL contains any valid information, the UI automatically recognizes the OS type and image category for you. If not, you can also manually specify those corresponding labels on the UI.

image::image-labels.png[]
20 changes: 10 additions & 10 deletions versions/v1.7/modules/en/pages/virtual-machines/vm-images/upload-image.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ To import virtual machine images in the *Images* page, enter a URL that can be a
+
[NOTE]
====
* The image name will be auto-filled using the file name in the URL address. You can customize the image name at any time.
* The image name is auto-filled using the file name in the URL address. You can customize the image name at any time.
* Avoid using a daily build URL (for example, the https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img[Ubuntu Jammy daily build]). When all replicas of a Longhorn backing image are lost, Longhorn attempts to download the file again for self-healing purposes. Using a daily build URL is problematic because the URL itself changes, causing a checksum mismatch and a conflict that results in lost replicas.
====
+
Expand Down Expand Up @@ -65,7 +65,7 @@ resource "harvester_image" "opensuse154" {

== Upload Images via Local File

Currently, qcow2, raw, and ISO images are supported.
Currently, qcow2, raw and ISO images are supported.

[NOTE]
====
Expand All @@ -90,7 +90,7 @@ If {rancher-product-name} is deployed on an RKE2 cluster, perform the following
+
[,sh]
----
$ kubectl -n cattle-system edit ingress rancher
kubectl -n cattle-system edit ingress rancher
----

. Specify a value for `nginx.ingress.kubernetes.io/proxy-body-size`.
Expand All @@ -103,7 +103,7 @@ image:img-ingress-client-body.png[]

=== Prolonged Uploading of Large Images in {rancher-product-name} Multi-Cluster Management

If you upload a very large image (over 10 GB) from the *Multi-Cluster Management* screen on the {rancher-product-name} UI, the operation may take longer than usual and the image status (Uploading) may not change.
If you upload a large image (over 10 GB) from the *Multi-Cluster Management* screen on the {rancher-product-name} UI, the operation may take longer than usual and the image status (Uploading) may not change.

This behavior is related to _proxy-request-buffering_ in the ingress configuration, which is also specific to the cluster that is hosting {rancher-product-name}.

Expand All @@ -115,7 +115,7 @@ If {rancher-product-name} is deployed on an RKE2 cluster, perform the following
+
[,sh]
----
$ kubectl -n cattle-system edit ingress rancher
kubectl -n cattle-system edit ingress rancher
----

. Turn off `nginx.ingress.kubernetes.io/proxy-request-buffering`.
Expand All @@ -130,7 +130,7 @@ image:img-ingress-request-proxy-buffering.png[]

Starting with *v1.5.5*, Longhorn https://github.com/longhorn/backing-image-manager/pull/153[compresses backing images for downloading]. If you attempt to upload a compressed backing image, {harvester-product-name} rejects the attempt and displays the message *Upload failed: the uploaded file size xxxx should be a multiple of 512 bytes since Longhorn uses directIO by default* because the compressed data violates Longhorn's data alignment.

Before uploading, decompress backing images using the command `$ gzip -d <file name>`.
Before uploading, decompress backing images using the command `gzip -d <file name>`.

== Create Images via Volumes

Expand All @@ -144,17 +144,17 @@ When creating an image, you can select a xref:/storage/storageclass.adoc[Storage

[NOTE]
====
The image will not use the `StorageClass` selected here directly. It's just a `StorageClass` template.
The image does not use the `StorageClass` selected here directly. It is just a `StorageClass` template.

Instead, it will create a special StorageClass under the hood with a prefix name of `longhorn-`. This is automatically done by the {harvester-product-name} backend, but it will inherit the parameters from the StorageClass you have selected.
Instead, it creates a special StorageClass under the hood with a prefix name of `longhorn-`. This is automatically done by the {harvester-product-name} back-end, but it inherits the parameters from the StorageClass you have selected.
====

image::image-storageclass.png[]

== Image Labels

You can add labels to the image, which will help identify the OS type more accurately. Also, you can add any custom labels for filtering if needed.
You can add labels to the image, which helps identify the OS type more accurately. Also, you can add any custom labels for filtering if needed.

If your image name or URL contains any valid information, the UI will automatically recognize the OS type and image category for you. If not, you can also manually specify those corresponding labels on the UI.
If your image name or URL contains any valid information, the UI automatically recognizes the OS type and image category for you. If not, you can also manually specify those corresponding labels on the UI.

image::image-labels.png[]
16 changes: 8 additions & 8 deletions versions/v1.8/modules/en/pages/virtual-machines/vm-images/upload-image.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ To import virtual machine images in the *Images* page, enter a URL that can be a
+
[NOTE]
====
* The image name will be auto-filled using the file name in the URL address. You can customize the image name at any time.
* The image name is auto-filled using the file name in the URL address. You can customize the image name at any time.
* Avoid using a daily build URL (for example, the https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img[Ubuntu Jammy daily build]). When all replicas of a Longhorn backing image are lost, Longhorn attempts to download the file again for self-healing purposes. Using a daily build URL is problematic because the URL itself changes, causing a checksum mismatch and a conflict that results in lost replicas.
====
+
Expand Down Expand Up @@ -90,7 +90,7 @@ If {rancher-product-name} is deployed on an RKE2 cluster, perform the following
+
[,sh]
----
$ kubectl -n cattle-system edit ingress rancher
kubectl -n cattle-system edit ingress rancher
----

. Specify a value for `nginx.ingress.kubernetes.io/proxy-body-size`.
Expand All @@ -115,7 +115,7 @@ If {rancher-product-name} is deployed on an RKE2 cluster, perform the following
+
[,sh]
----
$ kubectl -n cattle-system edit ingress rancher
kubectl -n cattle-system edit ingress rancher
----

. Turn off `nginx.ingress.kubernetes.io/proxy-request-buffering`.
Expand All @@ -130,7 +130,7 @@ image:img-ingress-request-proxy-buffering.png[]

Starting with *v1.5.5*, Longhorn https://github.com/longhorn/backing-image-manager/pull/153[compresses backing images for downloading]. If you attempt to upload a compressed backing image, {harvester-product-name} rejects the attempt and displays the message *Upload failed: the uploaded file size xxxx should be a multiple of 512 bytes since Longhorn uses directIO by default* because the compressed data violates Longhorn's data alignment.

Before uploading, decompress backing images using the command `$ gzip -d <file name>`.
Before uploading, decompress backing images using the command `gzip -d <file name>`.

== Create Images via Volumes

Expand All @@ -144,17 +144,17 @@ When creating an image, you can select a xref:/storage/storageclass.adoc[Storage

[NOTE]
====
The image will not use the `StorageClass` selected here directly. It's just a `StorageClass` template.
The image does not use the `StorageClass` selected here directly. It is just a `StorageClass` template.

Instead, it will create a special StorageClass under the hood with a prefix name of `longhorn-`. This is automatically done by the {harvester-product-name} backend, but it will inherit the parameters from the StorageClass you have selected.
Instead, it creates a special StorageClass under the hood with a prefix name of `longhorn-`. This is automatically done by the {harvester-product-name} back-end, but it inherits the parameters from the StorageClass you have selected.
====

image::image-storageclass.png[]

== Image Labels

You can add labels to the image, which will help identify the OS type more accurately. Also, you can add any custom labels for filtering if needed.
You can add labels to the image, which helps identify the OS type more accurately. Also, you can add any custom labels for filtering if needed.

If your image name or URL contains any valid information, the UI will automatically recognize the OS type and image category for you. If not, you can also manually specify those corresponding labels on the UI.
If your image name or URL contains any valid information, the UI automatically recognizes the OS type and image category for you. If not, you can also manually specify those corresponding labels on the UI.

image::image-labels.png[]