The handoff sets the transferred PersistentVolume to Retain so the data
survives the window in which the Forklift claim is deleted and claimRef
is re-pointed at the VMDisk's claim. It never gave the policy back, so
every imported disk kept Retain for good while its StorageClass says
Delete. Deleting such a VMDisk removes its DataVolume and claim through
the normal path and strands the volume Released with its backing
storage, billed and out of any tenant's reach.
Retain is now held only while it protects something. Once the new
claim and the volume both report Bound to each other, the transferred
claim is gone, and CDI has adopted the claim into the VMDisk
DataVolume as its only owner, the volume gets its class's policy back
(Delete when the class names none or no longer exists). The VMInstance
is created and the VM reported Succeeded only after that, so a task
that fails later still leaves disks that clean up like any other.
Assisted-by: LLM
Signed-off-by: Mattia Eleuteri <mattia@hidora.io>
Hidora's customers are leaving VMware now, and a tenant has to be able to
import their own machines without a platform administrator. The chart
approach could not express that: a tenant can neither create the Secret
holding vCenter credentials nor name the VDDK image, so both had to come
from somewhere they cannot reach.
Two CRDs in a new `forklift.cozystack.io` group, split by lifecycle. A
VMImportSource is a long-lived connection -- type, endpoint, credentials,
readiness -- and a VMImportTask is the one-shot operation that names
machines and produces VMDisks and VMInstances. The outputs carry no owner
reference back to the task, so deleting a finished import leaves the
machines alone. Konveyor Forklift does the transfer underneath; the
controller renders its objects, mirrors its verdicts, and hands each
finished volume into a VMDisk without copying it.
What a live vCenter migration forced out, and no amount of source reading
would have:
- A guest copied verbatim keeps the drivers it had under VMware and no
virtio, so on a virtio disk it does not fail the import -- it succeeds
and then does not boot. Imported disks go on SATA.
- VDDK connects straight to the ESXi host at the address vCenter
advertises, which is routinely unreachable, and on the first cluster
collided with the Service CIDR. `spec.hosts` redirects per host.
- Firmware must be carried across or a UEFI guest imports as BIOS and
never boots (stacked on #3002).
- Deleting a task mid-transfer orphaned its DataVolume; a finalizer now
removes the engine's volumes and leaves the outputs.
The console gains a Migration section: connections are editable, and the
VM field is a picker built from a machine list the controller publishes,
since the aggregated API cannot reach the inventory and should not hold a
source's credentials to try. Two general mechanisms fall out of that --
an option source may take an argument, and one named in a CRD annotation
may reference a sibling field.
Design: cozystack/community#62. Docs: cozystack/website#673.
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Mattia Eleuteri