|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * hosted_control_planes/hcp-manage/hcp-manage-virt.adoc |
| 4 | + |
| 5 | +:_mod-docs-content-type: PROCEDURE |
| 6 | +[id="hcp-virt-map-storage_{context}"] |
| 7 | += Mapping KubeVirt CSI storage classes |
| 8 | + |
| 9 | +KubeVirt CSI supports mapping a infrastructure storage class that is capable of `ReadWriteMany` (RWX) access. You can map the infrastructure storage class to hosted storage class during cluster creation. |
| 10 | + |
| 11 | +.Procedure |
| 12 | + |
| 13 | +* To map the infrastructure storage class to the hosted storage class, use the `--infra-storage-class-mapping` argument by running the following command: |
| 14 | ++ |
| 15 | +[source,terminal] |
| 16 | +---- |
| 17 | +$ hcp create cluster kubevirt \ |
| 18 | + --name <hosted_cluster_name> \ <1> |
| 19 | + --node-pool-replicas <worker_node_count> \ <2> |
| 20 | + --pull-secret <path_to_pull_secret> \ <3> |
| 21 | + --memory <memory> \ <4> |
| 22 | + --cores <cpu> \ <5> |
| 23 | + --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class> \ <6> |
| 24 | +---- |
| 25 | ++ |
| 26 | +<1> Specify the name of your hosted cluster, for instance, `example`. |
| 27 | +<2> Specify the worker count, for example, `2`. |
| 28 | +<3> Specify the path to your pull secret, for example, `/user/name/pullsecret`. |
| 29 | +<4> Specify a value for memory, for example, `8Gi`. |
| 30 | +<5> Specify a value for CPU, for example, `2`. |
| 31 | +<6> Replace `<infrastructure_storage_class>` with the infrastructure storage class name and `<hosted_storage_class>` with the hosted cluster storage class name. You can use the `--infra-storage-class-mapping` argument multiple times within the `hcp create cluster` command. |
| 32 | +
|
| 33 | +After you create the hosted cluster, the infrastructure storage class is visible within the hosted cluster. When you create a Persistent Volume Claim (PVC) within the hosted cluster that uses one of those storage classes, KubeVirt CSI provisions that volume by using the infrastructure storage class mapping that you configured during cluster creation. |
| 34 | + |
| 35 | +[NOTE] |
| 36 | +==== |
| 37 | +KubeVirt CSI supports mapping only an infrastructure storage class that is capable of RWX access. |
| 38 | +==== |
| 39 | + |
| 40 | +The following table shows how volume and access mode capabilities map to KubeVirt CSI storage classes: |
| 41 | + |
| 42 | +.Mapping KubeVirt CSI storage classes to access and volume modes |
| 43 | +|=== |
| 44 | +| Infrastructure CSI capability | Hosted cluster CSI capability | VM live migration support | Notes |
| 45 | + |
| 46 | +| RWX: `Block` or `Filesystem` |
| 47 | +| `ReadWriteOnce` (RWO) `Block` or `Filesystem` RWX `Block` only |
| 48 | +| Supported |
| 49 | +| Use `Block` mode because `Filesystem` volume mode results in degraded hosted `Block` mode performance. RWX `Block` volume mode is supported only when the hosted cluster is {ocp-short} 4.16 or later. |
| 50 | + |
| 51 | +| RWO `Block` storage |
| 52 | +| RWO `Block` storage or `Filesystem` |
| 53 | +| Not supported |
| 54 | +| Lack of live migration support affects the ability to update the underlying infrastructure cluster that hosts the KubeVirt VMs. |
| 55 | + |
| 56 | +| RWO `FileSystem` |
| 57 | +| RWO `Block` or `Filesystem` |
| 58 | +| Not supported |
| 59 | +| Lack of live migration support affects the ability to update the underlying infrastructure cluster that hosts the KubeVirt VMs. Use of the infrastructure `Filesystem` volume mode results in degraded hosted `Block` mode performance. |
| 60 | + |
| 61 | +|=== |
0 commit comments