diff --git a/platform/administer/node-providers/kubevirt.mdx b/platform/administer/node-providers/kubevirt.mdx index a0380e14d..7f3742630 100644 --- a/platform/administer/node-providers/kubevirt.mdx +++ b/platform/administer/node-providers/kubevirt.mdx @@ -17,6 +17,7 @@ When a vCluster requests a new node, the platform creates a KubeVirt `VirtualMac specific `NodeType` requested. To inspect and operate KubeVirt VMs directly from vCluster Platform, see [Virtual Machines](../virtual-machines/overview.mdx). +For administrator guidance on VM disk imports and Multus networks, see [Data Volumes](../virtual-machines/data-volumes.mdx) and [Network Attachment Definitions](../virtual-machines/network-attachment-definitions.mdx). This enables you to offer different "flavors" of virtual machines, for example small, medium, and large compute shapes, as nodes for your vCluster, all managed from a central configuration. @@ -490,6 +491,7 @@ This property is currently only compatible with standalone Machines. It cannot b ### Image configuration The image configuration properties synthesize a root-disk `DataVolumeTemplate`, volume, and disk and prepend them to the VM template. The synthesized disk is prepended to the VM's disk list, so it takes boot precedence over any other OS disks defined in the template. +For administrator workflows, ownership, and import troubleshooting, see [Data Volumes](../virtual-machines/data-volumes.mdx). #### `vcluster.com/os-image` @@ -590,6 +592,7 @@ When set, this overrides automatic network configuration. References a Multus `NetworkAttachmentDefinition` that already exists in the target namespace on the control plane cluster. The provider injects a `multus` network and a corresponding interface into the VM template using this NAD. If a network or interface with the same name already exists in the template, it is overwritten. This property is the supported way to attach a VM to an additional network such as a bridge. Set it on the NodeType for VMs that should share a network, or on the NodeClaim for a one-off attachment. +For UI workflows, examples, ownership, and NAD troubleshooting, see [Network Attachment Definitions](../virtual-machines/network-attachment-definitions.mdx). The following properties tune the injected interface. They only take effect when `kubevirt.vcluster.com/network-attachment-definition` is set. diff --git a/platform/administer/virtual-machines/data-volumes.mdx b/platform/administer/virtual-machines/data-volumes.mdx new file mode 100644 index 000000000..852296751 --- /dev/null +++ b/platform/administer/virtual-machines/data-volumes.mdx @@ -0,0 +1,315 @@ +--- +title: Data volumes +sidebar_label: Data volumes +sidebar_position: 2 +sidebar_class_name: pro +--- + +import Flow, {Step} from "@site/src/components/Flow"; +import FeatureTable from '@site/src/components/FeatureTable'; +import NavStep from "@site/src/components/NavStep"; +import Button from "@site/src/components/Button"; +import Label from "@site/src/components/Label"; + + + +KubeVirt `DataVolume` resources define the disk content that Containerized Data Importer (CDI) imports, clones, or creates for virtual machines. +In vCluster Platform, administrators use DataVolumes to prepare reusable VM disks, inspect import progress, and understand which VMs depend on a disk. + +Open the DataVolumes view from **Virtual Machines > Data Volumes**, or go directly to `/virtual-machines/data-volumes`. + +## When to use data volumes + +Use DataVolumes when you need to: + +- Import a VM disk from an HTTP, HTTPS, or registry source. +- Clone disk content from an existing PVC. +- Create a blank disk that a VM can format and use. +- Track the import, clone, or population status of a VM disk across connected KubeVirt clusters. +- Identify VMs that reference a DataVolume before changing or deleting it. + +## Prerequisites + +Before creating or using DataVolumes, make sure: + +- The target Control Plane Cluster is [connected to vCluster Platform](../clusters/connect-cluster.mdx). +- KubeVirt and CDI are installed on the target cluster, or the [KubeVirt node provider is configured to deploy them](../node-providers/kubevirt.mdx#infrastructure-deployment). +- The user has permission to list, create, update, and delete `datavolumes.cdi.kubevirt.io` resources in the target namespace. +- The StorageClass used by the DataVolume can provision PVCs in the target cluster. +- Image URLs, registries, PVC sources, secrets, and certificates are reachable from CDI importer pods. + +## Create a standalone data volume + +:::tip +Root disk DataVolumes for KubeVirt-backed Machines are usually generated automatically from [image properties](../node-providers/kubevirt.mdx#image-configuration) or an [OS image](../../use-platform/machines/os-images.mdx). Use the steps below to create a standalone DataVolume for reusable, secondary, or manually managed disks. +::: + +Use the platform UI when you want an administrator-managed DataVolume that can be referenced by one or more VMs. + + + + Open Virtual Machines > Data Volumes. + + + + Click . + + + + Choose the target KubeVirt cluster and namespace. + + + + Enter a name and storage size. + Select one source type: + + - : import from an HTTP or HTTPS image URL. + - : import from a container registry URL such as `docker://quay.io/containerdisks/ubuntu:22.04`. + - : clone from an existing PVC. + - : create an empty disk. + + + + Click and watch its lifecycle in the table. + + + +See the [CDI documentation](https://kubevirt.io/user-guide/storage/containerized_data_importer/) for the full set of source types and import semantics. + +The DataVolumes table shows the cluster, namespace, source type, requested storage, platform lifecycle status, and owner VMs. +Owner VMs appear when a VM references the volume. + +## Create a reusable data source + +To let multiple VMs reuse the same disk content without importing it more than once, wrap a DataVolume's PVC in a CDI `DataSource`. +Import or clone the disk once into a DataVolume through the platform UI, then create a `DataSource` that points to the resulting PVC: + +```yaml +apiVersion: cdi.kubevirt.io/v1beta1 +kind: DataSource +metadata: + name: ubuntu-22-04 + namespace: golden-images +spec: + source: + pvc: + name: ubuntu-root-disk + namespace: golden-images +``` + +Reference the DataSource from a NodeProvider, NodeType, NodeClaim, or Machine with `kubevirt.vcluster.com/image-datasource`, the same property described in [Import a root disk through a Machine](#import-a-root-disk-through-a-machine). + +vCluster Platform doesn't create or manage DataSource resources directly. Create and update them with `kubectl`, and treat them as long-lived golden images. +Deleting the underlying DataVolume or PVC breaks every VM that references the DataSource. + +## Understand the data volume lifecycle + +CDI reports the raw lifecycle in the DataVolume `.status.phase` field. +vCluster Platform maps that to a simplified **Status** column that groups related CDI phases. +Use the CDI phase when you troubleshoot with `kubectl`. Use the platform status when you scan the UI. + +| Platform status | Common CDI phases or signals | Meaning | +|---|---|---| +| `Importing` | `ImportScheduled`, `ImportInProgress` | CDI scheduled or started an image import. | +| `Pending` | `Pending`, `PVCBound`, clone phases, upload phases, `WaitForFirstConsumer`, `PendingPopulation` | CDI or the storage provider is preparing the PVC or waiting for scheduling. | +| `Ready` | `Succeeded` | CDI finished preparing the volume. | +| `Failed` | `Failed` or a `Running` condition with reason `Error` | CDI or the storage provider reported an error. | +| `Paused` | `Paused` | CDI paused the operation. | +| `Terminating` | `metadata.deletionTimestamp` is set | Kubernetes is deleting the DataVolume. | +| `Unknown` | Missing, empty, or unrecognized phase | The platform can't classify the lifecycle state. | + +For example, the UI can show `Pending` for a DataVolume whose CDI phase is `WaitForFirstConsumer`. +That usually means the PVC waits for a VM pod to schedule before the storage provider binds it. + +## Use data volumes with node providers + +The [KubeVirt node provider](../node-providers/kubevirt.mdx) can also synthesize a root-disk `DataVolumeTemplate` automatically when a Machine, NodeType, NodeProvider, or [OS image](../../use-platform/machines/os-images.mdx) sets `kubevirt.vcluster.com/image-url` or `kubevirt.vcluster.com/image-datasource`. +That generated DataVolume appears in the DataVolumes table alongside any administrator-created volumes. + +### Import a root disk through a Machine + +For VM-backed Machines and auto nodes, you usually do not need to create the root DataVolume manually. +Instead, set image properties on the KubeVirt provider, node type, NodeClaim, Machine, or referenced OSImage. + +```yaml +apiVersion: management.loft.sh/v1 +kind: NodeProvider +metadata: + name: kubevirt-provider +spec: + properties: + kubevirt.vcluster.com/image-url: docker://quay.io/containerdisks/ubuntu:22.04 + kubevirt.vcluster.com/root-disk-size: 20Gi + kubeVirt: + clusterRef: + cluster: kubevirt-host + namespace: vcluster-platform + virtualMachineTemplate: + spec: + template: + spec: + domain: + resources: + requests: + cpu: "2" + memory: 4Gi + nodeTypes: + - name: ubuntu + maxCapacity: 10 +``` + +The provider creates a root-disk `DataVolumeTemplate`, a volume, and a disk for the VM. +HTTP and HTTPS image URLs become CDI `http` sources. +`docker://` image URLs become CDI `registry` sources. + +To use a prepared CDI `DataSource`, set `kubevirt.vcluster.com/image-datasource` instead: + +```yaml +spec: + properties: + kubevirt.vcluster.com/image-datasource: golden-images/ubuntu-22-04 + kubevirt.vcluster.com/root-disk-size: 20Gi +``` + +Use `` to reference a DataSource in the VM namespace, or `/` to reference one in another namespace. +Do not set `kubevirt.vcluster.com/image-url` and `kubevirt.vcluster.com/image-datasource` together. + +### Attach data volumes to VM templates + +You can attach additional DataVolumes by adding a KubeVirt volume and disk to the VM template. +Use `dataVolumeTemplates` for volumes that should be created with the VM, or reference an existing DataVolume by name. + +Use `dataVolumeTemplates` for inline volumes: + +```yaml +spec: + kubeVirt: + virtualMachineTemplate: + spec: + dataVolumeTemplates: + - metadata: + name: tools-disk + spec: + source: + blank: {} + pvc: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi + template: + spec: + domain: + devices: + disks: + - name: tools-disk + disk: + bus: virtio + volumes: + - name: tools-disk + dataVolume: + name: tools-disk +``` + +When the KubeVirt node provider creates a VM from a template, it prefixes user-provided `dataVolumeTemplates` so DataVolume names stay unique for each node. + +To attach a standalone DataVolume that already exists in the VM namespace, reference it from the VM template's `volumes` list: + +```yaml +spec: + kubeVirt: + virtualMachineTemplate: + spec: + template: + spec: + domain: + devices: + disks: + - name: my-data-disk + disk: + bus: virtio + volumes: + - name: my-data-disk + dataVolume: + name: my-existing-datavolume +``` + +The referenced DataVolume must exist in the namespace where KubeVirt creates the VM. +This is the path to use for DataVolumes created through the **Data Volumes** UI. + +## Operational ownership + +DataVolumes are cluster resources, not vCluster Platform resources. +vCluster Platform gives administrators a UI for the connected KubeVirt clusters, but CDI owns the import and PVC population process. +KubeVirt owns DataVolumes created from a VM's `dataVolumeTemplates`, and those resources usually follow the VM lifecycle. + +Use this ownership model: + +| Owner | Responsibility | +|---|---| +| Platform administrator | Create reusable DataVolumes, choose storage classes, configure image sources, and control RBAC. | +| vCluster Platform | Lists DataVolumes, creates administrator-requested DataVolumes, shows platform lifecycle status and owner VMs, and generates root-disk templates from KubeVirt image properties. | +| CDI | Imports, clones, uploads, or populates PVC content and reports DataVolume phase and conditions. | +| KubeVirt | Creates DataVolumes from VM templates and attaches the resulting PVCs to VMs. | +| Storage provider | Provisions PVCs and enforces access modes, binding mode, expansion, and quota. | + +Before deleting a DataVolume, check the **Owner VMs** column or inspect VM volumes with `kubectl`. +Deleting a DataVolume or its PVC while a VM references it can prevent the VM from starting or can detach required disk content. + +## Troubleshoot data volumes + +### Import is stuck or slow + +Check the raw CDI phase and DataVolume conditions in the namespace where the DataVolume was created: + +```bash +kubectl get datavolume -n vcluster-platform +kubectl describe datavolume -n vcluster-platform ubuntu-root-disk +``` + +If the phase stays `ImportScheduled`, `ImportInProgress`, `WaitForFirstConsumer`, or `PendingPopulation`, inspect CDI importer pods and PVC events. + +```bash +kubectl get pods -n vcluster-platform -l cdi.kubevirt.io +kubectl describe pvc -n vcluster-platform ubuntu-root-disk +``` + +Common causes are an unreachable image URL, missing registry credentials, an invalid certificate ConfigMap, storage quota, an unavailable StorageClass, or a StorageClass with `WaitForFirstConsumer` binding that needs the VM pod to schedule before the PVC binds. + +### Data source can't be resolved + +If a VM or Machine uses `kubevirt.vcluster.com/image-datasource`, verify the DataSource exists in the expected namespace: + +```bash +kubectl get datasource -A +kubectl describe datasource -n golden-images ubuntu-22-04 +``` + +Use `name` for a DataSource in the VM namespace and `namespace/name` for a DataSource in a different namespace. +Also confirm the referenced DataSource points to a valid PVC or VolumeSnapshot and that RBAC allows CDI and KubeVirt to read it. + +### Virtual machine console opens but the guest doesn't boot + +Inspect the VM's disks and DataVolumes: + +```bash +kubectl get vm -n vcluster-platform my-vm -o yaml +kubectl get datavolume -n vcluster-platform +``` + +The root disk must be present in both `spec.template.spec.domain.devices.disks` and `spec.template.spec.volumes`. +For provider-generated root disks, `kubevirt.vcluster.com/root-disk-size` is required whenever `kubevirt.vcluster.com/image-url` or `kubevirt.vcluster.com/image-datasource` is set. +If the image boots but does not join a tenant cluster, make sure the guest image supports `cloudInitNoCloud`. + +### Data volume fails + +Describe the DataVolume and review CDI importer logs: + +```bash +kubectl describe datavolume -n vcluster-platform ubuntu-root-disk +kubectl logs -n vcluster-platform -l cdi.kubevirt.io +``` + +Failures usually point to source access, authentication, checksum mismatch, unsupported image format, insufficient storage, or storage provider errors. +After correcting the source or storage issue, recreate the DataVolume if CDI cannot retry the failed import. diff --git a/platform/administer/virtual-machines/network-attachment-definitions.mdx b/platform/administer/virtual-machines/network-attachment-definitions.mdx new file mode 100644 index 000000000..ce69f7583 --- /dev/null +++ b/platform/administer/virtual-machines/network-attachment-definitions.mdx @@ -0,0 +1,229 @@ +--- +title: Network attachment definitions +sidebar_label: Network attachment definitions +sidebar_position: 3 +sidebar_class_name: pro +--- + +import Flow, {Step} from "@site/src/components/Flow"; +import FeatureTable from '@site/src/components/FeatureTable'; +import NavStep from "@site/src/components/NavStep"; +import Button from "@site/src/components/Button"; + + + +Multus `NetworkAttachmentDefinition` resources describe additional Kubernetes networks that KubeVirt VMs can attach to. +Use them when a VM needs a bridge, VLAN, SR-IOV network, or another CNI-backed network in addition to, or instead of, the default pod network. + +Open the Network Attachment Definitions view from **Virtual Machines > Network Attachment Definitions**, or go directly to `/virtual-machines/network-attachment-definitions`. + +## When to use network attachment definitions + +Use a network attachment definition when the default pod network isn't suitable for VM traffic. Common examples are reaching an external L2 network or underlay, or controlling IPAM and other networking details explicitly. + +Also use network attachment definitions to: + +- Attach KubeVirt VMs to an existing Multus network. +- Make a Multus network the VM's default network. +- Provide L2 access through a bridge such as `br0` or a Netris-created bridge. +- Standardize network attachments across KubeVirt node types. +- Inspect or create NAD resources across connected KubeVirt clusters from the platform UI. + +The KubeVirt node provider attaches VMs to a NAD when the effective properties include `kubevirt.vcluster.com/network-attachment-definition`. +The property can be set on a NodeProvider, NodeType, NodeClaim, Machine, or [NodeEnvironment](../node-providers/overview.mdx#node-environments). + +## Prerequisites + +Before creating or using a NAD, make sure: + +- The target Control Plane Cluster is [connected to vCluster Platform](../clusters/connect-cluster.mdx). +- [KubeVirt](../node-providers/kubevirt.mdx#infrastructure-deployment), Multus, and the CNI plugins referenced by the NAD are installed on the target cluster. +- The user has permission to list, create, update, and delete `network-attachment-definitions.k8s.cni.cncf.io` resources in the target namespace. +- The referenced host bridge, device, VLAN, or network exists on the nodes where VM launcher pods can schedule. + +## Create a network attachment definition + +Use the platform UI to create an administrator-managed NAD in the namespace the VMs will use. After saving, reference the NAD name from a node type or NodeClaim as described in [Reference a NAD from a node type](#reference-a-nad-from-a-node-type). + + + + Open Virtual Machines > Network Attachment Definitions. + + + + Click . + + + + Choose the target KubeVirt cluster and namespace. + + + + Configure the network. + + - Enter the NAD name. + - Add the Container Network Interface (CNI) configuration as JSON. + + + + Click . + + + +The UI validates that `spec.config` is valid JSON before saving. +The following bridge example matches the placeholder used by the create form: + +```yaml +apiVersion: k8s.cni.cncf.io/v1 +kind: NetworkAttachmentDefinition +metadata: + name: bridge-network + namespace: vcluster-platform +spec: + config: | + { + "cniVersion": "0.3.1", + "name": "bridge-network", + "type": "bridge", + "bridge": "br0", + "ipam": { + "type": "host-local", + "subnet": "10.10.0.0/24" + } + } +``` + +The exact CNI configuration depends on your network plugin and node setup. +For example, a bridge NAD requires the named Linux bridge to exist on the relevant cluster nodes. + +## Reference a NAD from a node type + +Set [`kubevirt.vcluster.com/network-attachment-definition`](../node-providers/kubevirt.mdx#kubevirt-vcluster-com-network-attachment-definition) to the NAD name. +Use `` for a NAD in the VM namespace or `/` for a NAD in another namespace. + +```yaml +apiVersion: management.loft.sh/v1 +kind: NodeProvider +metadata: + name: kubevirt-bridge-provider +spec: + properties: + kubevirt.vcluster.com/image-url: docker://quay.io/containerdisks/ubuntu:22.04 + kubevirt.vcluster.com/root-disk-size: 20Gi + kubeVirt: + clusterRef: + cluster: kubevirt-host + namespace: vcluster-platform + virtualMachineTemplate: + spec: + template: + spec: + domain: + resources: + requests: + cpu: "2" + memory: 4Gi + nodeTypes: + - name: bridge-vm + properties: + kubevirt.vcluster.com/network-attachment-definition: bridge-network + kubevirt.vcluster.com/interface-binding: bridge + maxCapacity: 5 +``` + +When this property is set, the provider injects a KubeVirt network named `multus` and a matching interface named `multus`. +If a network or interface with that name already exists in the VM template, the provider overwrites it. +Only one NAD can be attached to a VM through this property. +To attach multiple additional networks, define the extra KubeVirt networks and interfaces directly in `virtualMachineTemplate`. + +Use these optional properties to tune the injected interface: + +| Property | Description | +|---|---| +| `kubevirt.vcluster.com/interface-binding` | Sets the KubeVirt binding method. Supported values are `bridge`, `masquerade`, `sriov`, `passt`, and `slirp`. Defaults to `bridge`. | +| `kubevirt.vcluster.com/interface-template` | YAML fragment merged into the injected KubeVirt interface. The interface name is always forced to `multus`. | +| `kubevirt.vcluster.com/multus-default` | When set to `"true"`, makes the Multus network the default network and removes the pod network from the VM template. | +| `kubevirt.vcluster.com/network-data` | Base64-encoded cloud-init network data. Use this when automatic network configuration is not enough. See [network-data templates](../../use-platform/machines/machine-config-templates.mdx#network-data-templates). | +| `kubevirt.vcluster.com/network-interface` | Guest interface name to configure, for example `enp1s0` or `eth1`. | +| `kubevirt.vcluster.com/network-nameservers` | Comma-separated DNS nameservers for generated network data. | + +## Use with Netris integration + +:::note +This section only applies if the Netris integration is enabled on your cluster. +::: + +Netris doesn't create the NAD itself. It provisions the underlying bridge network that the NAD references. +When the Netris integration is enabled and `netris.vcluster.com/server-cluster` is set, vCluster Platform creates or updates a Multus NAD automatically. +The generated name follows the Netris server cluster and node provider configuration, and the provider then attaches the VM through `kubevirt.vcluster.com/network-attachment-definition`. + +If you set `kubevirt.vcluster.com/network-attachment-definition` yourself, the Netris flow uses that existing NAD instead of creating another one. +See the [KubeVirt node provider Netris example](../node-providers/kubevirt.mdx#netris-integration) for the full provider configuration. + +## Operational ownership + +NetworkAttachmentDefinitions are cluster resources. +vCluster Platform can create, list, edit, and delete them from the VM networking UI, but Multus and the referenced CNI plugin own the actual network attachment behavior. + +Use this ownership model: + +| Owner | Responsibility | +|---|---| +| Platform administrator | Creates NADs, validates CNI JSON, verifies host networking, and assigns RBAC. | +| vCluster Platform | Lists and creates NADs, filters them to KubeVirt-enabled clusters, and injects NAD references into KubeVirt VMs through node provider properties. | +| Multus | Reads the NAD and attaches the requested network to the VM launcher pod. | +| CNI plugin | Implements the network described by `spec.config`. | +| KubeVirt | Connects VM interfaces to the pod networks and enforces interface/network name matching. | + +Treat NAD changes as infrastructure changes. +Changing `spec.config` can affect new VM starts immediately and may affect running workloads after restart or migration. + +## Troubleshoot network attachment definitions + +### Network attachment definition doesn't appear in the UI + +The Network Attachment Definitions view lists resources from connected clusters where KubeVirt is installed. +If a NAD is missing, verify the cluster is connected, KubeVirt is detected, and the resource exists: + +```bash +kubectl get network-attachment-definitions -A +kubectl get kubevirt -A +``` + +Also check RBAC for the user and the platform agent on `network-attachment-definitions.k8s.cni.cncf.io`. + +### Virtual machine fails to start after adding a network attachment definition + +Describe the VM and VMI: + +```bash +kubectl describe vm -n vcluster-platform my-vm +kubectl describe vmi -n vcluster-platform my-vm +``` + +Common causes are a missing NAD, invalid `spec.config` JSON, a CNI plugin that is not installed on the node, a missing host bridge or device, or an unsupported interface binding. +If `kubevirt.vcluster.com/multus-default` is `"true"`, the provider removes the pod network because KubeVirt rejects a VM with both a default Multus network and the pod network. + +### Virtual machine console works but networking doesn't + +Confirm that the Multus interface was injected into the VM template: + +```bash +kubectl get vm -n vcluster-platform my-vm -o yaml +``` + +The VM should have a network named `multus` and an interface named `multus`. +Then check that cloud-init config targets the guest interface name that the OS actually uses. +The VM template, cloud-init network data, and guest OS interface names must agree on which interface receives the configured IP address. +For generated network data, set `kubevirt.vcluster.com/network-interface` to the guest interface name and set `kubevirt.vcluster.com/network-nameservers`. + +### Network attachment definition configuration is invalid + +Validate the JSON in `spec.config` and confirm the CNI plugin accepts the fields: + +```bash +kubectl get network-attachment-definition -n vcluster-platform bridge-network -o yaml +``` + +The platform UI catches malformed JSON, but it cannot verify that a referenced bridge, VLAN, SR-IOV device, IPAM range, or plugin-specific option exists on every node. +Review Multus and CNI plugin logs on the target cluster if the JSON is valid but attachment still fails. diff --git a/platform/administer/virtual-machines/overview.mdx b/platform/administer/virtual-machines/overview.mdx index 5184c6cfa..492415d27 100644 --- a/platform/administer/virtual-machines/overview.mdx +++ b/platform/administer/virtual-machines/overview.mdx @@ -112,7 +112,8 @@ The VM management views cover: |---|---| | `VirtualMachine` | Desired VM configuration and run strategy. | | `VirtualMachineInstance` | Running VM instance status, phase, IP addresses, and console access. | -| `DataVolume` | Persistent disk content imported or cloned through CDI. | +| [`DataVolume`](./data-volumes.mdx) | Persistent disk content imported or cloned through CDI. | +| [`NetworkAttachmentDefinition`](./network-attachment-definitions.mdx) | Multus network definition that can attach VMs to additional networks. | | `VirtualMachineSnapshot` | Snapshot request for a VM. | | `VirtualMachineRestore` | Restore request from a VM snapshot. | @@ -181,6 +182,7 @@ Common properties include: | `kubevirt.vcluster.com/network-data` | Provides base64-encoded cloud-init network data. | | `kubevirt.vcluster.com/network-attachment-definition` | Attaches the VM to a NetworkAttachmentDefinition. | +For standalone storage and networking administration, see [Data Volumes](./data-volumes.mdx) and [Network Attachment Definitions](./network-attachment-definitions.mdx). For the full provider configuration, template behavior, image properties, and Netris networking example, see the [KubeVirt node provider documentation](../node-providers/kubevirt.mdx). ## Access control