Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
12 changes: 12 additions & 0 deletions hosted_control_planes/hcp-deploy/hcp-deploy-virt.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -54,13 +54,25 @@ With {product-title} 4.14 and later, you can create a cluster with KubeVirt, to

include::modules/hcp-virt-create-hc-cli.adoc[leveloffset=+2]

[role="_additional-resources"]
.Additional resources

* xref:../../hosted_control_planes/hcp-prepare/hcp-distribute-workloads.adoc#hcp-labels-taints_hcp-distribute-workloads[Labeling management cluster nodes]

include::modules/hcp-virt-create-hc-ext-infra.adoc[leveloffset=+2]

[role="_additional-resources"]
.Additional resources

* xref:../../hosted_control_planes/hcp-prepare/hcp-distribute-workloads.adoc#hcp-labels-taints_hcp-distribute-workloads[Labeling management cluster nodes]

include::modules/hcp-virt-create-hc-console.adoc[leveloffset=+2]

[role="_additional-resources"]
.Additional resources

* xref:../../hosted_control_planes/hcp-prepare/hcp-distribute-workloads.adoc#hcp-labels-taints_hcp-distribute-workloads[Labeling management cluster nodes]

* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.16/html/clusters/cluster_mce_overview#creating-a-credential-for-an-on-premises-environment[Creating a credential for an on-premises environment]

* xref:../../hosted_control_planes/hcp-manage/hcp-manage-virt.adoc#hcp-virt-access_hcp-manage-virt[Accessing the hosted cluster]
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,10 @@ include::modules/hcp-virt-reqs.adoc[leveloffset=+2]

include::modules/hcp-virt-create-hc-cli.adoc[leveloffset=+2]

[role="_additional-resources"]
.Additional resources
* xref:../../hosted_control_planes/hcp-prepare/hcp-distribute-workloads.adoc#hcp-labels-taints_hcp-distribute-workloads[Labeling management cluster nodes]

include::modules/hcp-virt-ingress-dns.adoc[leveloffset=+2]

[id="hcp-dc-virt-ingress-dns-custom"]
Expand Down
48 changes: 26 additions & 22 deletions modules/hcp-virt-create-hc-cli.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,13 @@
[id="hcp-virt-create-hc-cli_{context}"]
= Creating a hosted cluster with the KubeVirt platform by using the CLI

To create a hosted cluster, you can use the hosted control plane command-line interface (CLI), `hcp`.
[role="_abstract"]
To create a hosted cluster on {VirtProductName}, you can use the hosted control plane command-line interface (CLI), `hcp`.

[IMPORTANT]
====
Avoid storing all hosted cluster information in a shared namespace. If you create a hosted cluster in a shared namespace and then back up and restore the hosted cluster, you might unintentionally change other hosted clusters. Either store hosted cluster information in a separate namespace or set up your hosted cluster to back up and restore resources based on labels.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

set up your hosted cluster to back up and restore resources based on labels

Will the typical user know what this means/how to do this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I can add an xref in an Additional resources section that links to the docs about using labels.

====

.Procedure

Expand All @@ -16,30 +22,28 @@ To create a hosted cluster, you can use the hosted control plane command-line in
[source,terminal]
Copy link
Copy Markdown
Contributor Author

@lahinson lahinson Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The remainder of the changes in this file replace the number callouts with a list to prepare this document for migration to AEM.

----
$ hcp create cluster kubevirt \
--name <hosted_cluster_name> \// <1>
--node-pool-replicas <node_pool_replica_count> \// <2>
--pull-secret <path_to_pull_secret> \// <3>
--memory <value_for_memory> \// <4>
--cores <value_for_cpu> \// <5>
--etcd-storage-class=<etcd_storage_class> \// <6>
--arch <architecture_of_the_nodepool> \// <7>
--release-image <ocp_release_image_for_the_cluster> <8>
--name <hosted_cluster_name> \
--node-pool-replicas <node_pool_replica_count> \
--pull-secret <path_to_pull_secret> \
--memory <value_for_memory> \
--cores <value_for_cpu> \
--etcd-storage-class=<etcd_storage_class> \
--arch <architecture_of_the_nodepool> \
--release-image <ocp_release_image_for_the_cluster>
----
<1> Specify the name of your hosted cluster, for example, `my-hosted-cluster`.
<2> Specify the node pool replica count, for example, `3`. You must specify the replica count as `0` or greater to create the same number of replicas. Otherwise, no node pools are created.
<3> Specify the path to your pull secret, for example, `/user/name/pullsecret`.
<4> Specify a value for memory, for example, `6Gi`.
<5> Specify a value for CPU, for example, `2`.
<6> Specify the etcd storage class name, for example, `lvm-storageclass`.
<7> Specify the architecture of the node pool, for example, `s390x`. The default is `amd64`.
<8> Specify the ocp release image for the cluster, for example, `quay.io/openshift-release-dev/ocp-release:4.20.14-multi`.
+
[NOTE]
====
You can use the `--release-image` flag to set up the hosted cluster with a specific {product-title} release.
====
--
* `--name` defines the name of your hosted cluster, for example, `my-hosted-cluster`.
* `--node-pool-replicas` defines the node pool replica count, for example, `3`. You must specify the replica count as `0` or greater to create the same number of replicas. Otherwise, no node pools are created.
* `--pull-secret` defines the path to your pull secret, for example, `/user/name/pullsecret`.
* `--memory` defines a value for memory, for example, `6Gi`.
* `--cores` defines a value for CPU, for example, `2`.
* `--etcd-storage-class` defines the etcd storage class name, for example, `lvm-storageclass`.
* `--arch` defines the architecture of the node pool, for example, `s390x`. The default is `amd64`.
* `--release-image` defines the {product-title} release image for the cluster, for example, `quay.io/openshift-release-dev/ocp-release:4.20.14-multi`. You can use the `--release-image` flag to set up the hosted cluster with a specific {product-title} release.
--
+
A default node pool is created for the cluster with two virtual machine worker replicas according to the `--node-pool-replicas` flag.
A default node pool is created for the cluster with a specific number of virtual machine worker replicas according to the `--node-pool-replicas` flag.

. After a few moments, verify that the hosted control plane pods are running by entering the following command:
+
Expand Down
16 changes: 11 additions & 5 deletions modules/hcp-virt-create-hc-console.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,13 @@
[id="hcp-virt-create-hc-console_{context}"]
= Creating a hosted cluster by using the console

To create a hosted cluster with the KubeVirt platform by using the console, complete the following steps.
[role="_abstract"]
If you prefer to work in the {product-title} console instead of the CLI, you can create a hosted cluster on the KubeVirt platform by using the console.

[NOTE]
====
If you want to use predefined values to automatically populate fields in the console, you can create a {VirtProductName} credential. For more information, see "Creating a credential for an on-premises environment".
====

.Procedure

Expand All @@ -20,11 +26,11 @@ To create a hosted cluster with the KubeVirt platform by using the console, comp

. On the *Create cluster* page, follow the prompts to enter details about the cluster and node pools.
+
[NOTE]
On the *Cluster details* page, the pull secret is your {product-title} pull secret that you use to access {product-title} resources. If you selected a {VirtProductName} credential, the pull secret is automatically populated.
+
[IMPORTANT]
====
* If you want to use predefined values to automatically populate fields in the console, you can create a {VirtProductName} credential. For more information, see "Creating a credential for an on-premises environment".

* On the *Cluster details* page, the pull secret is your {product-title} pull secret that you use to access {product-title} resources. If you selected a {VirtProductName} credential, the pull secret is automatically populated.
Avoid storing all hosted cluster information in a shared namespace. If you create a hosted cluster in a shared namespace and then back up and restore the hosted cluster, you might unintentionally change other hosted clusters. Either store hosted cluster information in a separate namespace or set up your hosted cluster to back up and restore resources based on labels.
====

. On the *Node pools* page, expand the *Networking options* section and configure the networking options for your node pool:
Expand Down
42 changes: 24 additions & 18 deletions modules/hcp-virt-create-hc-ext-infra.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@
[id="hcp-virt-create-hc-ext-infra_{context}"]
= Creating a hosted cluster with the KubeVirt platform by using external infrastructure

[role="_abstract"]
By default, the HyperShift Operator hosts both the control plane pods of the hosted cluster and the KubeVirt worker VMs within the same cluster. With the external infrastructure feature, you can place the worker node VMs on a separate cluster from the control plane pods.

- The _management cluster_ is the {product-title} cluster that runs the HyperShift Operator and hosts the control plane pods for a hosted cluster.
Expand All @@ -14,6 +15,11 @@ By default, the HyperShift Operator hosts both the control plane pods of the hos

- By default, the management cluster also acts as the infrastructure cluster that hosts VMs. However, for external infrastructure, the management and infrastructure clusters are different.

[IMPORTANT]
====
Avoid storing all hosted cluster information in a shared namespace. If you create a hosted cluster in a shared namespace and then back up and restore the hosted cluster, you might unintentionally change other hosted clusters. Either store hosted cluster information in a separate namespace or set up your hosted cluster to back up and restore resources based on labels.
====

.Prerequisites

* You must have a namespace on the external infrastructure cluster for the KubeVirt nodes to be hosted in.
Expand All @@ -22,28 +28,28 @@ By default, the HyperShift Operator hosts both the control plane pods of the hos

.Procedure
Copy link
Copy Markdown
Contributor Author

@lahinson lahinson Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The remainder of the changes in this file replace the number callouts with a list to prepare this document for migration to AEM.


You can create a hosted cluster by using the `hcp` command-line interface.

* To place the KubeVirt worker VMs on the infrastructure cluster, use the `--infra-kubeconfig-file` and `--infra-namespace` arguments, as shown in the following example:
* In the `hcp` command-line interface, place the KubeVirt worker VMs on the infrastructure cluster, use the `--infra-kubeconfig-file` and `--infra-namespace` arguments, as shown in the following example:
+
[source,terminal]
----
$ hcp create cluster kubevirt \
--name <hosted-cluster-name> \// <1>
--node-pool-replicas <worker-count> \// <2>
--pull-secret <path-to-pull-secret> \// <3>
--memory <value-for-memory> \// <4>
--cores <value-for-cpu> \// <5>
--infra-namespace=<hosted-cluster-namespace>-<hosted-cluster-name> \// <6>
--infra-kubeconfig-file=<path-to-external-infra-kubeconfig> <7>
--name <hosted-cluster-name> \
--node-pool-replicas <worker-count> \
--pull-secret <path-to-pull-secret> \
--memory <value-for-memory> \
--cores <value-for-cpu> \
--infra-namespace=<hosted-cluster-namespace>-<hosted-cluster-name> \
--infra-kubeconfig-file=<path-to-external-infra-kubeconfig>
----
+
<1> Specify the name of your hosted cluster, for example, `my-hosted-cluster`.
<2> Specify the worker count, for example, `2`.
<3> Specify the path to your pull secret, for example, `/user/name/pullsecret`.
<4> Specify a value for memory, for example, `6Gi`.
<5> Specify a value for CPU, for example, `2`.
<6> Specify the infrastructure namespace, for example, `clusters-example`.
<7> Specify the path to your `kubeconfig` file for the infrastructure cluster, for example, `/user/name/external-infra-kubeconfig`.
--
** `--name` defines the name of your hosted cluster, for example, `my-hosted-cluster`.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes we use two asterisks at the beginning like here, sometimes we use just one (like in modules/hcp-virt-create-hc-cli.adoc. Is this intentional? Does it matter? Thanks

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mgencur Good question! The number of asterisks indicates how indented the list is. This list has two asterisks because it's nested under an unordered list item (the asterisk on line 31).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Thanks

** `--node-pool-replicas` defines the worker count, for example, `2`.
** `--pull-secret` defines the path to your pull secret, for example, `/user/name/pullsecret`.
** `--memory` defines a value for memory, for example, `6Gi`.
** `--cores` defines a value for CPU, for example, `2`.
** `--infra-namespace` defines the infrastructure namespace, for example, `clusters-example`.
** `--infra-kubeconfig-file` defines the path to your `kubeconfig` file for the infrastructure cluster, for example, `/user/name/external-infra-kubeconfig`.
--
+
After you enter that command, the control plane pods are hosted on the management cluster that the HyperShift Operator runs on, and the KubeVirt VMs are hosted on a separate infrastructure cluster.
After you enter the command, the control plane pods are hosted on the management cluster that the HyperShift Operator runs on, and the KubeVirt VMs are hosted on a separate infrastructure cluster.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want this sentence that far over?

Image

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved