mirror of
https://github.com/cozystack/cozystack.git
synced 2026-10-28 23:57:08 +09:00
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>
25 lines
916 B
YAML
25 lines
916 B
YAML
migrationController:
|
|
image: "ghcr.io/cozystack/cozystack/migration-controller:latest"
|
|
replicas: 1
|
|
debug: false
|
|
metrics:
|
|
enabled: true
|
|
bindAddress: ":8443"
|
|
resources:
|
|
requests:
|
|
cpu: 10m
|
|
memory: 64Mi
|
|
limits:
|
|
cpu: 500m
|
|
memory: 256Mi
|
|
|
|
## The VMware Virtual Disk Development Kit image, delivered from the platform.
|
|
## Never a tenant value: naming an image the cluster will run is not a tenant's
|
|
## decision, and this one is built from a proprietary SDK that Cozystack can
|
|
## neither ship nor mirror. An operator holding a VDDK licence builds it, pushes
|
|
## it somewhere the cluster can pull from, and sets `vmImport.vddkImage` in the
|
|
## platform values, which the iaas bundle forwards into this chart.
|
|
## Empty is the normal state and means the vSphere import path is unavailable
|
|
## rather than broken: a vSphere VMImportSource reports it on its own status.
|
|
vddkImage: ""
|