seedV2vReviewStepCollections adds the migrated VM's pool and SRs to what seedV2vListPool seeds instead of seeding the list pool and its default SRs again
The 7 job tests checking the "in progress" error of a running job use expectJobRunning; the V2V idle job tests check canRun alone, as the other job tests (canRun is the absence of error).
Every V2V selected VM and source VM check a test expects comes from V2V_SELECTED_VM_CHECK, V2V_VM_CHECK or createV2vUnsupportedCheck, built from literals so a broken getV2vUnsupportedCheck fails its tests.
- useV2vPoolName names a pool through getV2vTargetName
- useV2vImportVm names the pool of an import VM and reads its active mapping, used by useV2vResumedVm and the review step
- useV2vSelectedVms exposes getRow and getName, used by the review step
- mountV2vListStep replaces mountV2vMappingStep and mountV2vReviewStep
- useXoV2vStartJob posts the launch to the pool import route and returns
its task id, without monitoring it: an import lasts hours
- useV2vLaunchForm: stop the source VMs and stop on error by default, two
VMs at a time, concurrency an integer from 1 to 8 as the back end accepts
- Dev mock: the import route answers a task id, or the problems the back
end would refuse the launch for
- New test helper: createV2vStartPayloadInput, the input of buildV2vStartPayload
- getV2vLaunchPlan groups the list VMs as the selected VMs panel checks them
(excluded, already migrated, resumed, new) and keeps the launchable ones,
an already migrated VM only once confirmed
- getV2vVmStopSource / setV2vVmStopSource: the stop source option of a VM,
from the launch settings or its override; resolveV2vValue now gives the
value and origin of any V2V override (resolveV2vTarget builds on it)
- buildV2vStartPayload sends only what the back end accepts (no start, no
cleanup, no tags, MACs kept), no mapping for a resumed VM;
getV2vStartProblems reads the problems of a refused launch
- getV2vCutoverAt: the date of the complete import snapshot
- getUnprocessableEntityData shared by the V2V connection and start errors
- New test helpers: createApiError, V2V_SELECTED_VM_CHECK, the V2V launch
factories and createV2vCompleteImportSnapshot
The resumed VM and VM actions tests read it without mounting a mapping. The actions test only needs a
connection to open the drawer under: it gets a plain one.
- The drawer is an overlay rendered at the app root, out of the migration page: reading the V2V connection there
threw, so Edit settings opened nothing
- useV2vVmTargets: the targets and options the drawer edits, read from an inventory handed in; useV2vVmMapping adds
the pool name, host and checks of the side panel on top
- useV2vVmSettingsEdit hands the drawer the inventory of the connected source
- Tests: the drawer is mounted without the wizard connection; v2vMappingConnectionProvide shared by the mapping tests
- seedV2vListPool takes partial offers and the other pool, and sets the collections itself: seedChoices is gone
- the wizard, pool name and source-and-destination tests seed the list pool through it
- createV2vMigrationListVmsOf builds the list VMs of given ids, replacing the hand-written ones; V2vMappingStep reads the stored VM through readV2vStoredListVm
- `seedV2vListPool` seeds the pool of the list and its offers, in place of
the same two lines in the VMs step, selected VMs and mapping step tests
- the resumed VM is imported to the pool of the list: `V2V_RESUMED_VM_POOL`
is gone
- the network and template of the other pool get their own ids, apart from
the list defaults
- mock-overlay.ts records each useOverlay call, in order, as its options and the open spy it returned
- used by the backup repository, plugin drawer job and V2V settings tests, in place of 7 hand-written mocks
- createV2vOfferedTarget: a resolved target among the pool offers
- V2V_LIST_VM_OVERRIDES, V2V_FULLY_OVERRIDDEN_LIST_VM, V2V_OTHER_LIST_VM: the list VMs the mapping tests start from
- V2V_NEW_STEP_VM, V2V_RESUMED_STEP_VM, V2V_NOT_FOUND_STEP_VM: one mapping step VM of each kind
- describeV2vMappingCardLayout, countDividers: the layout the side panel mapping cards share
- mountV2vVmKindActions, findV2vRouteQuery
- the drawer cancel cases, the table menu order and the panel kind switch no longer re-test what another test covers
Edit settings opens a drawer holding the per-VM settings of a new VM on a
draft: SR per disk, network per NIC, keep MAC, template and tags. Save
replaces the stored overrides of the VM once, Cancel writes nothing.
The options card becomes V2vVmOptionsFields, so the drawer reuses them.
The VM mapping reads its overrides from an injectable source, so that
useV2vVmMappingDraft edits a copy of them and hands back the changed
overrides, without writing the stored list.
- per-VM overrides in the migration list (disks, NICs, template, keep MAC,
tags), parsed with their shape
- one mapping resolver: each target from its override or the list default,
offered or not, and the mapping complete or incomplete
- `mapping-incomplete` check of a new VM, after `partial-on-other-pool`
- mapping summary from the resolved mapping, with distinct target names
- source VM checks (unsupported disks, snapshots), next transfer (delta or
full), datacenter of the VM
- active mapping of a resumed VM: disk to VDI by its `esxi_diskPath` in the
disk chain, NIC to VIF by device, MAC kept or not
