design-proposals: VM import from VMware vSphere

[Andrei Kvapil (kvaps)]

Design proposal for migrating VMware vSphere virtual machines into Cozystack, on the Konveyor Forklift engine that cozystack/cozystack#1982 already vendors.

Opened as a draft: the shape is settled, the load-bearing mechanics are verified (see below), but the upstream Forklift seccomp knob described in Design §4 is not yet submitted, and the full flow has not been run against a real vCenter yet.

Why this is here rather than in the implementation PR

cozystack/cozystack#1982 works and has been validated by its author on a live cluster, but its review surfaced questions that are design questions rather than defects: whether a VMware import is a tenant application at all, how a tenant supplies credentials when tenants cannot create Secrets, and whether an import produces managed Cozystack objects or leaves raw Forklift PVCs behind. Settling those in an 81-file PR is more expensive than settling them here.

What it proposes

The tenant API is a pair of CRDs in a new migration.cozystack.io group, reconciled by a controller in core — the shape of Cozystack's own Backup API (BackupJob/RestoreJob), not a Helm chart in the catalog. A VMImportSource registers a long-lived connection to a provider: type, endpoint, credentials entered on the spec, materialized into a Secret by the controller, validated against the live endpoint before anything is created. A VMImportTask runs the one-shot operation: reference a source, name the VMs, get VMDisks and VMInstances. The outputs carry no ownerReference to the Task, so deleting a Task removes the migration machinery and never the imported objects; everything Forklift-internal is owned and garbage-collected.

This follows the shape proposed in the implementation PR's review. An earlier revision of this proposal kept a catalog app plus a VMDisk source extension; it lost to the Backup precedent, which already answers one-shot lifecycle, tenant RBAC (aggregation labels shipped by the owning package), dashboard rendering (schema-generated forms and option pickers on plain CRDs), and controller-side credential materialization. The Alternatives section records the comparison.

A fulfillment controller drives one Forklift Plan per source VM and hands each transferred volume into its VMDisk without a second copy, using cdi.kubevirt.io/storage.populatedFor — the same primitive Cozystack's Velero VM-restore path already depends on in production. That closes both the raw-PVC gap raised in review and the duplicate-copy waste tracked in cozystack/cozystack#3924.

The proprietary VDDK image never enters the tree: it is an optional platform value the operator sets, delivered to the migration controller, and no image field appears on any tenant API.

The privilege story, verified live

On the raw-copy path no Forklift pod moves the bytes — CDI's importer does, through SetRestrictedSecurityContext. Verified in source against Forklift v2.11.5 / CDI v1.64.0 and empirically on a running Cozystack v1.6.2 cluster: the import was admitted into a restricted-enforcing namespace with no PodSecurity denial and ran to completion. Tenant self-service is structurally possible today.

Guest conversion is the constrained path, and its requirement is four syscalls (unshare, mount, umount2, pivot_root), not privilege: libguestfs starts passt, which sandboxes itself into fresh namespaces. baseline and restricted both accept seccompProfile.type: Localhost, and Forklift already selects a Localhost profile — but only when it detects OpenShift (pkg/controller/conversion/builder.go on current main). kubev2v/forklift#4491 is open on exactly this. The proposal pairs a node-side profile shipped through Talos machine.seccompProfiles with a small upstream setting in the VIRT_V2V_* family; a patch in that shape is already built and unit-tested. The privileged-namespace-plus-Unconfined-webhook shape is explicitly rejected.

Status of the claims

Everything load-bearing is cited to file:line. Two claims were additionally verified on a live cluster: restricted-PSS admission of the transfer pod, and the copy-free populatedFor handoff (same PV throughout, no importer pod, data byte-identical) — which also surfaced two constraints now folded into §5 (volumeMode/accessModes must be copied from the PV; the owning DataVolume must be deleted before re-pointing). Nothing has been measured against a real vCenter — the timings quoted are the implementation author's. The ## Open questions section carries a recommended default for each unsettled point.

Requesting review from the reviewers of cozystack/cozystack#1982, whose findings shaped this, and from the contributor whose implementation it builds on.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: e29e2758-677f-41b7-aaf2-a0c0c42bc730

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}