#Introduction

For enterprises using a virtual machine-based architecture, transitioning to a Kubernetes and container-based architecture inevitably requires application modernization. However, due to constraints such as the need for continuous business uptime or the difficulty in changing development habits, enterprises often cannot completely disengage from virtualization architecture in a short period.

Therefore, a solution that can uniformly configure, manage, and control container resources and virtual machine resources on the same platform becomes particularly important.

#Container-Orchestrated Virtual Machine Solution

This platform implements a virtual machine (VMI, VirtualMachineInstance) solution based on the open-source component KubeVirt, allowing for easier and faster creation of container-orchestrated virtual machines and running virtualized applications.

#Features

Rapid Transformation

There is no need to rewrite applications or modify images. Simply package the existing application into a qcow2 or raw format virtual machine image, and create a virtual machine using that image on the platform, allowing the application to be deployed to the container platform.

Maintain Behavioral Habits

Containerized virtual machines can be managed using a similar approach to traditional virtual machines, without needing to focus on the underlying container implementation, including virtual machine lifecycle management, disks and networks, and snapshot management.

Coexistence of Virtualization and Containerization

• The unified platform supports managing virtualized services while also enabling Kubernetes-based container scheduling and management.

• On the basis of continuing to use virtual machine workloads, it allows for a gradual modernization of containerized applications.

• The development of new containerized applications that need to interact with virtualized applications remains unaffected.

#Product Features

• Virtual Machine: Supports creating virtual machines with images allocated by administrators and managing them, including starting and stopping virtual machines, managing snapshots, remote login to virtual machines, and modifying virtual machine configurations.

• Virtual Disk: Supports viewing and managing disk information created in the current project, including creating disks, viewing disk names, storage classes, capacities, and associated virtual machines.

• Virtual Machine Snapshots: Supports viewing details such as the status of virtual machine snapshots, the associated virtual machine, and the most recent rollback time.

• Virtual Machine Images: Supports viewing virtual machine image information under the current project, including image provision method and operating system.

• Key Pairs: Supports viewing and managing key pairs created in the current project, including creating key pairs and viewing the list of associated virtual machines.

• Bootable Volumes: Manage golden-image boot sources across namespaces, with four import sources (HTTP/HTTPS, container registry, clone PVC, clone snapshot).

• Live Migration: Migrate a running virtual machine between nodes without downtime, governed by cluster-wide migration limits and per-namespace migration policies.

• Storage Migration: Move a running virtual machine's disks between storage classes online.

• More lifecycle actions: Clone a whole virtual machine, pause and resume it, and open a serial console (text TTY) or VNC console.

#How Console Features Map to API Objects

#Architecture and Permissions

The platform's virtualization is built on KubeVirt and CDI, managed by the HyperConverged (HCO) operator:

• HyperConverged (HCO) is the single source of truth — it deploys and continuously reconciles KubeVirt and CDI. Cluster-level settings (such as live-migration limits) must be set on the HyperConverged resource, not directly on KubeVirt.
• CDI (Containerized Data Importer) imports and clones disk images into PVCs — the engine behind bootable volumes and virtual machine disks.
• virt-controller schedules virtual machines, virt-handler runs on each node, and virt-launcher wraps each running virtual machine in a pod.

To delegate access, bind the KubeVirt cluster roles in a namespace:

CDI provides matching cdi.kubevirt.io:view / :edit / :admin roles for managing DataVolumes and DataSources.

#Constraints and Limitations

It must be implemented based on a physical machine cluster, and KubeVirt components must be deployed within the cluster with virtualization enabled. The platform provides the capability to deploy KubeVirt components via Operator and an interface to enable virtualization, with all related configurations completed by the platform administrator.