--- title: "KubeVirt CDI" source: "https://www.tigera.io/learn/guides/kubevirt/kubevirt-cdi/" description: "KubeVirt Containerized Data Importer (CDI) is an open-source Kubernetes extension for managing virtual machine (VM) disk images." --- ## Guides: KubeVirt CDI # KubeVirt Containerized Data Importer (CDI): Basics and Tutorial - [KubeVirt](https://www.tigera.io/learn/guides/kubevirt/) - [KubeVirt CDI](https://www.tigera.io/learn/guides/kubevirt/kubevirt-cdi/) - [KubeVirt Architecture](https://www.tigera.io/learn/guides/kubevirt/kubevirt-architecture/) - [Kubevirt Live Migration](https://www.tigera.io/learn/guides/kubevirt/kubevirt-live-migration/) ## What Is KubeVirt Containerized Data Importer (CDI)? [KubeVirt](https://www.tigera.io/learn/guides/kubevirt/) Containerized Data Importer (CDI) is an open-source Kubernetes extension for managing virtual machine (VM) disk images. It enables users to import, upload, clone, and convert disk images into Kubernetes PersistentVolumes, integrating VM storage operations with native Kubernetes workflows. CDI is crucial for managing VM lifecycle events in KubeVirt, such as provisioning VM disks from local images, URLs, or other clusters. CDI abstracts the process of handling disk images, supporting multiple formats like QCOW2 and RAW, and offering mechanisms for frequent VM image management tasks. By leveraging Kubernetes-native constructs like Custom Resource Definitions (CRDs), CDI brings automation, permission management, and consistent storage interface to virtual machine disk import and export, ensuring VMs have the storage needed for efficient operation. **In this article:** - Benefits of Using KubeVirt CDI - The Role of CDI in the KubeVirt Architecture - How KubeVirt CDI Works - Quick Tutorial: Uploading Local Disk Images to KubeVirt Using CDI - Best Practices for Using KubeVirt CDI - Common Challenges When Operating CDI at Scale - Evaluation Criteria for CDI Networking and Security ## Benefits of Using KubeVirt CDI There are several reasons for organizations to use KubeVirt CDI: - **Simplified and automated VM image management:** CDI reduces manual work by automating the process of importing, converting, and preparing VM disk images. Instead of writing custom scripts or managing each import individually, users define desired states declaratively, and CDI handles the rest. - **Kubernetes-native workflow for VM disk lifecycle:** Using Kubernetes Custom Resource Definitions (CRDs) such as DataVolume, CDI allows VM disk image operations to be expressed as part of a Kubernetes manifest. This aligns image management with GitOps, CI/CD pipelines, and infrastructure-as-code models, enabling reproducible and version-controlled infrastructure changes. - **Standardized and repeatable image handling processes:** CDI enforces consistent procedures for handling VM images across environments. This ensures imported images follow the same steps regardless of source or target cluster, reducing variability and simplifying troubleshooting. - **Strong integration with Kubernetes storage ecosystem:** CDI supports multiple Kubernetes StorageClass configurations and dynamic provisioning. This allows it to work seamlessly with a variety of storage backends, including block and file systems, and enables easy adaptation to different infrastructure setups. - **Flexible data import options:** Users can import VM images from various sources including HTTP/HTTPS URLs, container image registries, existing PVCs, or local uploads via CDI’s Upload Proxy. This flexibility supports a wide range of use cases, from developer testing to production-scale image distribution. - **Built-in security features for image uploads:** Security is built into CDI’s upload mechanisms. It uses TLS for encrypted transfers, token-based authentication to control access, and scoped permissions to restrict operations to authorized users. These features help protect VM image integrity and prevent unauthorized uploads. - **Scalable for large VM environments:** CDI is designed to handle many image operations in parallel. This scalability makes it suitable for cloud-native environments with large VM fleets or multi-tenant clusters, where high-throughput image processing is essential. ## The Role of CDI in the KubeVirt Architecture CDI acts as the storage bridge within KubeVirt’s architecture, simplifying the process of getting VM disk images into the cluster and making them usable by VMs. Without CDI, administrators must manually download, convert, and attach disk images as Kubernetes PersistentVolumeClaims (PVCs), adding unnecessary complexity. When a new VM is defined, the storage requirements are also defined through DataVolumes, triggering CDI to manage the backend operations. As a result, VM image distribution and management become as seamless as container image handling. CDI turns virtual disk importation into an orchestrated, native Kubernetes process. CDI fits into the cluster’s networking and storage layers by acting as both a consumer and producer of Kubernetes storage resources. On the storage side, CDI provisions PVCs by interacting with the underlying StorageClass, dynamically allocating space for VM disks. It leverages Kubernetes volume binding and storage provisioning logic to ensure disk images are placed on the correct backend, whether it’s local storage, NFS, or a cloud-native CSI driver. On the networking side, CDI initiates data transfers during imports from external sources, such as HTTP(S) servers or registries, and handles uploads through the CDI Upload Proxy. This proxy is a secure, internal service exposed to authenticated clients and operates within the Kubernetes service network. CDI uses standard Kubernetes networking to move data from external or user-facing sources into the cluster’s persistent storage, ensuring the disk image reaches the PVC tied to the target VM. This integration ensures that image imports respect network policies, security boundaries, and resource constraints in the cluster. ***Learn more in our detailed guide to* *[KubeVirt architecture](https://www.tigera.io/learn/guides/kubevirt/kubevirt-architecture/)*** ## How KubeVirt CDI Works KubeVirt CDI automates the population of Kubernetes PersistentVolumeClaims (PVCs) with VM disk images or other data, using a declarative model. This is done primarily through a custom Kubernetes resource called a DataVolume, which abstracts and extends the capabilities of standard PVCs. When a DataVolume is created, CDI automatically provisions the associated PVC and populates it with the specified data source. CDI supports several data sources for populating volumes: - **HTTP or HTTPS URL**: Downloads an image from a remote location using a dedicated pod. Authentication and custom TLS can be configured via Kubernetes secrets and config maps. - **Container registry**: Retrieves a container disk image from an OCI-compatible registry. This method requires the kubevirt content type and supports images built for KubeVirt. - **Clone of existing PVC**: Performs either an efficient backend clone or a secure pod-to-pod transfer, depending on the capabilities of the underlying storage. - **Client upload**: Sets up a secure upload proxy for authenticated users to push data directly into the cluster. A valid UploadToken is required to initiate the transfer. - **Empty disk creation**: Initializes a blank disk volume using the blank source. This is useful for provisioning new, unformatted VM disks. - **oVirt and VMware imports**: Supports importing virtual disks from existing virtualization platforms using their native APIs and credentials. Each DataVolume must specify a contentType, which tells CDI how to process the data. The two supported types are: - **kubevirt**: For VM disk images. CDI automatically handles decompression, format conversion (e.g., from QCOW2 to RAW), and resizing. - **archive**: For TAR archives, where CDI extracts the contents directly into the volume for use by containers or VMs. CDI runs as a controller in the Kubernetes cluster, watching for DataVolume objects and managing pods and resources to complete the data transfer. It is designed to be storage-agnostic and works with any Kubernetes-compatible storage class that supports PVC binding. ### Tips from the Expert In my experience, here are tips that can help you better scale and secure your use of KubeVirt CDI in production environments: #### Use volume pre-population in golden image pipelines: Create “golden” PVCs pre-populated with optimized and hardened OS images using DataVolumes, and clone them for VM provisioning. This dramatically reduces VM boot time and ensures consistency across dev/test/prod environments. #### Leverage smart cloning with CSI snapshots for performance: On CSI-compliant storage backends that support snapshot cloning, configure CDI to use Smart Cloning instead of pod-to-pod transfers. This speeds up large image provisioning and avoids unnecessary I/O, particularly in environments with high VM churn. #### Apply node affinity and tolerations for import pods: Control where CDI importer/uploader pods run by setting nodeAffinity and tolerations on DataVolume templates. This helps align storage workloads with high-I/O nodes or avoid placing disk-heavy tasks on sensitive nodes like control planes. #### Integrate CDI image uploads into CI/CD pipelines: Automate image uploads via virtctl in CI/CD stages (e.g., using GitLab runners or Tekton tasks). This enables on-demand image updates (e.g., OS patches or app preloads) with versioned tracking, rather than relying on manual uploads. #### Set PVC ownership metadata for lifecycle binding: Annotate PVCs and DataVolumes with ownerReferences to tie them explicitly to VirtualMachine resources. This enables Kubernetes garbage collection and avoids orphaned volumes that waste storage when VMs are deleted or fail. ![Profile Picture](https://www.tigera.io/app/uploads/2026/04/Dillon-Barry-150x150.jpeg) #### Dillon Barry Technical Marketing Engineer (TME) Dillon Barry is a Technical Marketing Engineer at Tigera. He has worked with Kubernetes and Cloud Native technologies for over 8 years at some of the largest and most forward thinking companies in the industry. Based in Ireland, Dillon has a wealth of experience across different roles and industries as a consultant and solutions architect, with a background at companies like Pivotal and VMware. Dillon has a Bachelor's degree in Computer Science and an interest in everything modern computing. ## Quick Tutorial: Uploading Local Disk Images to KubeVirt Using CDI To upload a local VM disk image into your KubeVirt cluster using the Containerized Data Importer (CDI), you’ll need a configured cluster with CDI installed, a valid disk image (e.g., .qcow2, .raw, or .iso), and the virtctl CLI tool available in your environment. Instructions in this tutorial are adapted from the official [Kubevirt documentation](https://kubevirt.io/user-guide/storage/containerized_data_importer/). ### 1. Install CDI Install the latest version of CDI by applying the operator and custom resource manifests: ``` `export TAG=$(curl -s -w %{redirect_url} https://github.com/kubevirt/containerized-data-importer/releases/latest) export VERSION=$(echo ${TAG##*/}) kubectl create -f https://github.com/kubevirt/containerized-data-importer/releases/download/$VERSION/cdi-operator.yaml kubectl create -f https://github.com/kubevirt/containerized-data-importer/releases/download/$VERSION/cdi-cr.yaml` ``` ![Output of installing the CDI operator and custom resource](https://www.tigera.io/app/uploads/2026/10/kubevirt-cdi-tutorial-01.jpg) ### 2. Expose the Upload Proxy The cdi-uploadproxy service must be reachable from your local environment. You can expose it using methods like NodePort, Ingress, or OpenShift Routes. For development clusters, kubectl port-forward may be used, though it’s not suitable for production. We can use the following command: ``` `kubectl -n cdi port-forward svc/cdi-uploadproxy 31001:443` ``` ![Output of port-forwarding the cdi-uploadproxy service](https://www.tigera.io/app/uploads/2026/10/kubevirt-cdi-tutorial-02.jpg) Alternatively, set a permanent upload proxy URL using: ``` `kubectl patch cdi cdi \ --type merge \ --patch '{"spec":{"config":{"uploadProxyURLOverride":"https://cdi-uploadproxy:31001"}}}'` ``` ![Output of patching the CDI upload proxy URL override](https://www.tigera.io/app/uploads/2026/10/kubevirt-cdi-tutorial-03.jpg) Ensure DNS or local host resolution supports the name cdi-uploadproxy. ### 3. Prepare the Image Ensure your local image file is in a supported format: .qcow2, .raw, or .iso. Compression with .gz or .xz is supported. For example, you might use Fedora-Cloud-Base.raw.xz. You can download it using the following command: ``` `wget https://dl.fedoraproject.org/pub/fedora/linux/releases/43/Cloud/x86_64/images/Fedora-Cloud-Base-AmazonEC2-43-1.6.x86_64.raw.xz` ``` ![Output of downloading the Fedora Cloud Base image with wget](https://www.tigera.io/app/uploads/2026/10/kubevirt-cdi-tutorial-04.jpg) ### 4. Upload the Image Using virtctl To upload a local image to a new DataVolume: ``` `virtctl image-upload dv fedora-dv \ --size=10Gi \ --image-path=/path/to/image.qcow2 \ --uploadproxy-url=https://cdi-uploadproxy:31001` ``` ![Output of uploading the image to a DataVolume with virtctl image-upload](https://www.tigera.io/app/uploads/2026/10/kubevirt-cdi-tutorial-05.jpg) If the DataVolume already exists, use –no-create. For uploads to a PVC instead of a DataVolume, replace dv with pvc. The upload process will: - Create the DataVolume - Request an upload token - Transfer the image via cdi-uploadproxy - Populate the PVC automatically ### 5. Troubleshooting Certificate Issues If you see errors like x509: certificate signed by unknown authority, this is due to self-signed certificates. To fix, export the upload proxy certificate: ``` `kubectl get secret -n cdi cdi-uploadproxy-server-cert \ -o jsonpath="{.data['tls\.crt']}" \ | base64 -d > cdi-uploadproxy-server-cert.crt` ``` Add it to your system’s trusted certificates (on Fedora): ``` `sudo cp cdi-uploadproxy-server-cert.crt /etc/pki/ca-trust/source/anchors sudo update-ca-trust` ``` If necessary, you can bypass verification with –insecure, though this is not recommended for production. ### 6. Create a VirtualMachineInstance (VMI) Once uploaded, you can use the DataVolume as a disk in a VMI: ``` `apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance metadata: name: cirros-vm spec: domain: devices: disks: - name: dvdisk disk: bus: virtio resources: requests: memory: 64M volumes: - name: dvdisk dataVolume: name: cirros-vm-disk` ``` Apply the manifest: ``` `kubectl apply -f vmi.yaml` ``` ![Output of applying the VirtualMachineInstance manifest](https://www.tigera.io/app/uploads/2026/10/kubevirt-cdi-tutorial-06.jpg) ### 7. Connect to the VM Console Use virtctl to open a terminal session: ``` `virtctl console cirros-vm` ``` ![Console output of the VM booting, ending at the login prompt](https://www.tigera.io/app/uploads/2026/10/kubevirt-cdi-tutorial-07.jpg) This process simplifies VM provisioning by integrating image upload directly into Kubernetes-native workflows using CDI and virtctl. ## Best Practices for Using KubeVirt CDI Here are some practices to consider when using CDI and KubeVirt ### 1. Keep CDI and KubeVirt Versions in Sync Ensuring that CDI and KubeVirt are on compatible versions is critical to the overall function and stability of your virtualization infrastructure. Both projects evolve in parallel, with new features, security updates, and bug fixes often relying on matched API versions or controller behaviors. Mismatched versions can result in failing CRDs, broken workflows, or unanticipated performance issues, all of which complicate VM management in production. Careful upgrade planning is necessary. Before upgrading, validate compatibility by consulting the official documentation or using supported installation channels like OperatorHub. Always test upgrades in a staging environment before applying them in production. Automating version checks and alerts for outdated components can further reduce the risk of drift between CDI and KubeVirt, allowing for proactive maintenance rather than reactive troubleshooting. ### 2. Use Dedicated StorageClasses for VM Images VM disks come with storage performance demands that differ from standard container workloads. Using dedicated StorageClasses for VM images ensures that disks are provisioned with the right performance, availability, and backup settings required for consistent virtual machine uptime. Isolating VM images to specific StorageClasses also simplifies backup, archiving, and disaster recovery policies. To implement this, create StorageClasses optimized for block storage with tuning for IOPS or latency as needed by your virtualization workloads. Assign these StorageClasses as defaults for CDI DataVolumes or specify them explicitly in your DataVolume resources. This prevents accidental placement of VM disks on underperforming volumes and offers easy paths to migrate or scale storage independently of general cluster storage operations. ### 3. Automate Image Imports via DataVolume Templates Automating image import with DataVolume templates standardizes how VM images are pulled or uploaded across environments. Instead of writing repetitive import manifests, templates let users define source image locations, storage requirements, and transformation steps just once. Developers and operations can then reuse these templates for day-to-day provisioning or in CI/CD pipelines, ensuring consistent and repeatable results with minimal manual intervention. DataVolume templates integrate with Kubernetes’ declarative model, allowing for version control and peer review of storage policies and sources. This approach speeds onboarding for new team members and supports automated compliance checks. Integrate the template workflow with GitOps or Infrastructure as Code (IaC) strategies to further reduce manual errors and enforce best practices at scale. ### 4. Monitor CDI Pods and Resource Usage Monitoring CDI pods is essential for identifying workflow failures, bottlenecks, and resource consumption patterns in your cluster. By tracking the health and status of importer, uploader, and controller pods, teams can quickly detect and address failing image uploads, capacity shortages, or API errors. Metric collection from CDI integrates natively with Prometheus and other cloud-native monitoring solutions, enabling real-time alerts and visibility. Resource usage monitoring, including CPU, memory, and disk throughput prevents performance degradation, especially in clusters with high VM creation and migration demands. Threshold-based alerts proactively inform administrators when scaling CDI components or cluster resources becomes necessary. ### 5. Secure Upload Proxy and TLS Configuration Securing the CDI upload proxy and its TLS configuration is crucial, as uploading disk images can expose sensitive data or introduce attack vectors. By default, CDI’s upload service uses a TLS-enabled endpoint to ensure traffic encryption, but administrators must verify that certificates are current, properly signed, and trusted across the cluster. Restrict access to the upload proxy by enforcing authentication, such as requiring valid Kubernetes service account tokens or integrating with cluster RBAC policies. Regularly rotate TLS certificates and audit upload proxy logs for unauthorized or anomalous access attempts. For additional security, use network policies to limit the exposure of uploader pods and services, and ensure firewall rules only allow traffic from trusted networks or authorized CI/CD runners. ### 6. Apply Fine-Grained Network Policies for CDI Components To protect the data plane and reduce the cluster’s attack surface, apply fine-grained Kubernetes network policies around CDI components such as the upload proxy, importer, and clone pods. These components interact with both external sources and internal services, making them sensitive points of ingress and egress that require tight controls. Start by segmenting CDI pods into a dedicated namespace and defining default deny-all policies to block unsolicited traffic. Then, explicitly allow only the necessary communications, such as HTTPS traffic to the upload proxy or internal access from CDI controllers to storage backends. For upload operations, restrict ingress to the upload proxy from known IP ranges or trusted service accounts. Similarly, limit importer pods’ egress to known image sources and registry domains. This approach minimizes lateral movement risk and ensures data transfers occur only between approved endpoints. Use tools like Calico or Cilium for enhanced network policy enforcement, and continuously validate policy effectiveness using network observability tools or test pods. ### 7. Ensure Observability of CDI Data Transfer Flows Enable observability by collecting metrics, logs, and traces from CDI components involved in image imports, uploads, and cloning operations. CDI exposes Prometheus metrics through its controller and transfer pods, including data transfer durations, failure rates, and queue depths. Scrape these metrics to monitor trends like import throughput, average upload size, and error patterns. Set up alerts on critical indicators such as failed DataVolumes, stalled transfers, or high latency during imports. In addition to metrics, collect and centralize CDI pod logs for troubleshooting. Logs from importer, uploader, and clone pods provide detailed progress and error messages for each transfer. Tag logs with DataVolume names or namespaces to correlate with virtual machine operations. ## Common Challenges When Operating CDI at Scale Organizations operating Kubevirt CDI at scale often run into the following challenges: - **Ensuring secure uploads with multiple users or namespaces:** In multi-user or multi-namespace clusters, securing the CDI upload process becomes complex. Each upload must be scoped to the correct namespace, authenticated properly, and prevented from leaking data across tenant boundaries. CDI uses token-based authentication to secure uploads, but mismanagement of tokens, permissions, or service accounts can result in unauthorized access. - **Monitoring large or frequent data imports:** At scale, frequent or parallel image imports can overload storage backends or saturate network links. CDI spawns importer pods for each DataVolume, which may result in hundreds of concurrent data transfers during peak activity periods, especially in CI/CD-driven environments. - **Managing multi-tenant CDI access:** CDI must support multi-tenant access while preventing resource conflicts and ensuring isolation. Without strict controls, tenants could interfere with each other’s DataVolumes, overuse shared storage, or initiate unauthorized imports. - **Detecting misconfigurations or unexpected traffic patterns:** Misconfigured DataVolumes, such as incorrect image URLs, wrong content types, or untrusted sources, can lead to failed imports, stalled VMs, or increased attack surfaces. Unexpected traffic to CDI endpoints can indicate abuse, automation errors, or intrusion attempts. - **Guaranteeing compliance in VM image handling:** VM images often contain OS-level or application-specific configurations subject to internal or external compliance requirements. At scale, ensuring that all imported images meet security, licensing, and configuration baselines becomes challenging. - **Handling network bottlenecks and large image transfers:** Large image uploads or imports, especially over WAN links or in shared environments, can overwhelm network resources, leading to timeouts, incomplete transfers, or degraded performance for other workloads. Compression formats such as .qcow2.gz or .raw.xz can reduce transfer size. ## Evaluation Criteria for CDI Networking and Security Here are some of the ways organizations can ensure CDI implementation is secure and effective. ### 1. Support for Network Policy Enforcement Around CDI Components A strong CDI setup must support Kubernetes network policies that restrict ingress and egress to CDI components. The upload proxy, importer, and clone pods handle sensitive VM disk data and should be isolated from unnecessary cluster traffic. CDI should be evaluated for how well it integrates with tools like Calico. Ensure that each CDI component can be independently targeted by labels, and verify that applying deny-by-default policies does not break core functionality. This level of enforcement is essential to prevent unauthorized access and contain potential breaches. ### 2. Namespace-Aware Isolation of CDI Workloads CDI operations must respect Kubernetes namespace boundaries, especially in multi-tenant or regulated environments. All CDI workloads, including importer pods, PVCs, and DataVolumes, should be isolated to the namespace where they were initiated, with no cross-namespace access unless explicitly configured. Assess whether the CDI controller enforces namespace scoping and whether image uploads, clones, and imports are contained within the initiating namespace. Evaluate CDI’s use of service accounts and RBAC policies for namespace isolation and verify that it does not introduce shared resources that could violate tenant separation. ### 3. Observability of Data Import Flows (Pod/Service, Pod/External) CDI must provide clear visibility into its data flows: between importer pods and the upload proxy, external sources, or storage services. This helps detect bottlenecks, debug failures, and confirm expected behaviors in complex deployments. Check for support of Prometheus metrics exposing transfer latency, success/failure rates, and pod states. Log collection from CDI controller and transfer pods should offer detailed insights into each import event. Integration with tracing tools or service meshes (e.g., Istio) is a plus for tracking cross-service communication in large clusters. ### 4. Ability to Detect Suspicious or Non-Compliant Data Transfer Activity CDI should allow administrators to detect unauthorized or anomalous data transfer patterns that might indicate abuse, misconfiguration, or security incidents. Evaluate CDI for audit logging of upload and import events, with detail on user identity, image sources, and data size. Integration with security tooling (e.g., Falco, OPA, or SIEM platforms) should be possible to trigger alerts on unusual activities such as repeated failed imports, access to unapproved URLs, or transfers outside business hours. Network policy logs should also help correlate traffic patterns with CDI operations. ### 5. Multi-Cluster Consistency (If Using KubeVirt in Multi-Cluster Setups) In federated or multi-cluster KubeVirt deployments, CDI must behave consistently across clusters and integrate cleanly with centralized management systems. Image handling and security policies should be portable and enforceable in each environment. Look for support of GitOps workflows that replicate CDI configuration across clusters, and tools for syncing image templates or DataVolume definitions. Ensure CDI CRDs and controller behavior are version-aligned between clusters to avoid discrepancies. Consistent RBAC, network policy enforcement, and observability should also be validated as part of multi-cluster readiness. ### 6. Compatibility with VM Workloads and Kubernetes Pods CDI must handle both virtual machine disk images and, optionally, container pod volumes, especially when working in hybrid clusters. Compatibility with both KubeVirt VMs and native Kubernetes workloads expands its utility in shared environments. Verify that CDI supports mixed content types (e.g., kubevirt and archive) and can provision volumes usable by VMs or standard pods. Confirm that DataVolumes can be used seamlessly in different workload types without requiring special storage backends or modifications to pod specifications. This flexibility helps unify storage operations across virtualization and containerization. ### 7. Support for Zero Trust or Least-Privilege Networking A zero trust model requires that every CDI component follows the principle of least privilege, only communicating with authorized services and only when needed. Evaluate CDI’s architecture for how well it supports zero-trust patterns. Ensure that CDI uses short-lived, scoped tokens for upload operations, does not rely on privileged pods, and allows fine-grained RBAC for each operation (upload, clone, import). Network policies should block all unnecessary traffic by default. TLS encryption must be enforced on all communication paths, and CDI should support certificate rotation and validation. ## How Calico Delivers Unified Networking & Security for Pods and VMs In the vSphere world, VMs got their networking and security from one stack (NSX, vSwitches, hypervisor firewalls) and any containers running alongside them got it from somewhere else entirely. That split is the networking tax most platform teams are still paying. Calico collapses it: pods and VMs share the same data plane, the same policy model, and the same observability surface, so a workload’s type stops dictating how it’s networked, secured, or observed. Live migration between nodes becomes a consequence of that unification rather than a special case to engineer around. - **Calico L2 Bridge Networks for VM network continuity.** Calico creates a bridge on each cluster node and attaches a trunk interface, allowing the VM’s original VLAN, IP address, and MAC address to be carried directly into Kubernetes through a secondary interface (net1) on the virt-launcher pod. Multiple VLANs can share the same trunk-backed bridge, so the existing Layer 2 topology is preserved without per-VLAN infrastructure. - **Declarative network configuration.** Administrators define a Kubernetes network resource that tells Calico which VLAN to bridge and how to map it, and a NetworkAttachmentDefinition instructs KubeVirt to attach the secondary interface at boot. Migration tooling such as Forklift maps existing VM interfaces to these definitions and registers the VM’s IP with Calico before cutover. - **IP, VLAN, and MAC continuity for VM workloads.** Once Calico owns the VM’s network identity, it maintains routing state and binds that identity to the workload wherever it runs in the cluster. Firewall rules, DNS records, load balancer backends, and monitoring targets continue to resolve without change, and when KubeVirt live-migrates the VM between nodes, the upstream network sees no movement at all. - **eBPF-based observability across pods and VMs.** Calico provides traffic flow data, communication patterns, and east-west visibility for both pod and VM interfaces using eBPF, without per-host agents, taps, or external monitoring tooling. Platform teams get one telemetry surface for both workload types, and that telemetry stays consistent as VMs move across nodes during live migration. - **Kubernetes-native network policy on VM interfaces.** Calico network policy applies directly to VM interfaces using the same label and selector model used for containers, with selectors that can target specific VLANs or external networks. Existing hypervisor firewall rules can be migrated incrementally into version-controlled, auditable Calico policy, the same policy primitives your platform teams already use for pods. **Next Steps** - [Lift-and-Shift VMs to Kubernetes with Calico L2 Bridge Networks](https://www.tigera.io/blog/lift-and-shift-vms-to-kubernetes-with-calico-l2-bridge-networks/) – technical walkthrough of how Calico L2 Bridge Networks preserve VLANs and IPs during migration and across live migration between nodes. Add Tigera as a preferred source on Google to see more of our content in your search results. [![Add as a preferred source on Google](https://www.tigera.io/app/themes/tigera2021/dist/img/google-preferred-source-light.png)](https://www.google.com/preferences/source?q=tigera.io)