KubeVirt CSI Driver Installation¶
Official Repository:
Important
This CSI driver is made for a tenant cluster deployed on top of kubevirt VMs, and enables it to get its persistent data from the underlying, infrastructure cluster. To avoid confusion, this CSI driver is deployed on the tenant cluster, and does not require kubevirt installation at all.
Controller deployment on the Infra-Cluster¶
- Create a
Secretwithin the tenant-cluster project/namespace which contains the kube config of your tenant-cluster:
- Label the virtualized nodes (vms) accordingly so that the CSI Driver can pick up the labels in order to operate:
- Create a
ConfigMapwithin the tanant-cluster project which the KubeVirt CSI Controller is using to identify the tenant-cluster name via the label as well as the tenant-cluster namespace:
- Within the tenant-cluster namespace, create the
ServiceAccountas well as the controller:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 | |
KubeVirt CSI Driver installation on the Tenant-Cluster¶
- Create a new project named e.g.
kubevirt-csi-driver:
- Annotate the nodes with the annotations
csi.kubevirt.io/infra-vm-name=${node}as well ascsi.kubevirt.io/infra-vm-namespace=$NAMESPACE.
If the annotations doesn't exist, it'll fail with:
Warning
F0218 08:58:00.631541 1 kubevirt-csi-driver.go:32] Failed to initialize driver: failed to configure node service: failed to resolve infra VM for node "rguske-ocp42-cp1": vmName or vmNamespace not found. Ensure the node has a valid providerID (kubevirt://) with annotation 'cluster.x-k8s.io/cluster-namespace', or set annotations 'csi.kubevirt.io/infra-vm-name' and 'csi.kubevirt.io/infra-vm-namespace' on the node. After setting the annotations, restart the kubevirt-csi-node pod on this node for the changes to take effect
Resolution on GitHub:
- Install the complete CSI Driver:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 | |
In case the above mentioned error message appears anyway, delete the pods:
Deploy Example Pod with PVC¶
- create the pvc
- deploy the pod
Errors along the way¶
Cannot update subresources¶
Warning
I0218 09:56:57.327140 1 controller.go:456] failed adding volume pvc-4b21e668-de61-4df7-b20d-fde66144d747 to VM rguske-ocp42-n3, retrying, err: virtualmachines.subresources.kubevirt.io "rguske-ocp42-n3" is forbidden: User "system:serviceaccount:rguske-ocp42:kubevirt-csi" cannot update resource "virtualmachines/addvolume" in API group "subresources.kubevirt.io" in the namespace "rguske-ocp42"
The ServiceAccount (infra-cluster-serviceaccount.yaml) needed to be adjusted with the appropriate priviledges (resources + verbs). After fixing it, the volume could be attached:
Info
I0218 10:03:06.890836 1 server.go:121] /csi.v1.Controller/ControllerPublishVolume called with request: {"node_id":"rguske-ocp42/rguske-ocp42-n3","volume_capability":{"AccessType":{"Mount":{"fs_type":"ext4"}},"access_mode":{"mode":1}},"volume_context":{"bus":"scsi","serial":"c462f25e-3ba7-4f12-96ef-8013aee36760","storage.kubernetes.io/csiProvisionerIdentity":"1771401314268-2085-csi.kubevirt.io"},"volume_id":"pvc-c08d2bd3-c43c-4157-82ab-3fa81464bbd0"} I0218 10:03:06.901504 1 controller.go:403] Attaching DataVolume pvc-c08d2bd3-c43c-4157-82ab-3fa81464bbd0 to Node ID rguske-ocp42/rguske-ocp42-n3 I0218 10:03:06.907020 1 controller.go:430] Start attaching DataVolume pvc-c08d2bd3-c43c-4157-82ab-3fa81464bbd0 to VM rguske-ocp42-n3. Volume name: pvc-c08d2bd3-c43c-4157-82ab-3fa81464bbd0. Serial: c462f25e-3ba7-4f12-96ef-8013aee36760. Bus: scsi
Pod can't mount PVC¶
Warning
AttachVolume.Attach failed for volume "pvc-eb7ff8dc-ed38-473f-a5ea-4baa4686b0b9" : timed out waiting for external-attacher of csi.kubevirt.io CSI driver to attach volume pvc-eb7ff8dc-ed38-473f-a5ea-4baa4686b0b9
furthermore:
Warning
MountVolume.MountDevice failed for volume "pvc-eb7ff8dc-ed38-473f-a5ea-4baa4686b0b9" : rpc error: code = Unknown desc = couldn't find device by serial id
Existing KC articles:
On the Tenant CLuster¶
On the Infra-Cluster¶
Check the controller logs oc logs deploy/kubevirt-csi-controller -f
Checking the scsi controller which is used when hot-plugging a PVC:
The hotplug disk is attached as disk.bus: scsi and the serial is set correctly (5bcccca9-…).
But inside the guest you never see a second block device (only vda), so the CSI node can’t possibly find /dev/disk/by-id/
StorageClass fixed the Issue¶
I changed the StorageClass from odf-replica-two-block to ocs-storagecluster-ceph-rbd-virtualization. The difference between both sc's were the volumeBindingMode:. The working one has volumeBindingMode: Immediate.
Deployed the Pod with the PVC accordingly and:
StorageProfile Adjustments¶
Make sure that the AccessMode is configured for the StorageProfile otherwise, you'll get an error message for the respective DataVolume that the AccessMode is missing/not specified.
VirtLauncher Pod can't be scheduled¶
Check KubeVirt specific labels:
VolumeSnapshotContent Error¶
Warning
Failed to check and update snapshot content: failed to add VolumeSnapshotBeingCreated annotation on the content snapcontent-4860fa21-076c-49b1-9cbf-5b66407fbe72: "snapshot controller failed to update snapcontent-4860fa21-076c-49b1-9cbf-5b66407fbe72 on API server: VolumeSnapshotContent.snapshot.storage.k8s.io \"snapcontent-4860fa21-076c-49b1-9cbf-5b66407fbe72\" is invalid: spec: Invalid value: \"object\": sourceVolumeMode is required once set"'
Check whether your CRDs enforce sourceVolumeMode:
In Kubernetes snapshots, there are two relevant components:
- snapshot-controller (cluster-wide) - OpenShift provides this
- csi-snapshotter sidecar – runs inside the CSI driver controller deployment in my case, the KubeVirt CSI driver I've installed in the tenant cluster. It watches VolumeSnapshot/VolumeSnapshotContent and performs the CSI snapshot RPCs, and updates VolumeSnapshotContent objects.
Solution¶
I've deleted the associated CRDs:
