Cause. The disks of a running virtual machine were to move to another datastore, but its host runs the machine on the legacy runtime. Only Kyvernon VMM can copy the disks of a running machine and switch to the copies.
Remedy.
Power the virtual machine off and move its disks then: kyvernon vm power-off <id>, then kyvernon vm relocate <id> --datastore <datastore>.
Or move it first to a host that runs Kyvernon VMM.
error.storage_move.internal_snapshots
Text in the console
Disk {disk} holds internal snapshots, which cannot move while the virtual machine runs. Power it off, or remove those snapshots.
Meaning for API clients
The active image of the disk holds internal qcow2 snapshots, which a running VM cannot carry to another datastore.
Cause. The active image of the disk holds internal qcow2 snapshots. A running machine's image is copied block by block, and internal snapshots cannot travel that way. Images with internal snapshots come from the legacy runtime or from an import; Kyvernon VMM takes external snapshots.
Remedy.
Power the virtual machine off and move it then: a move of a powered-off machine copies the file with its snapshots.
Or remove those snapshots first.
error.storage_move.nonpersistent
Text in the console
Disk {disk} is independent non-persistent and moves only while the virtual machine is powered off.
Meaning for API clients
An independent non-persistent disk moves only while the VM is powered off.
Cause. The disk is independent non-persistent: its changes are discarded when the machine stops, and that discard layer cannot move while the machine runs.
Remedy.
Power the virtual machine off and move it then: kyvernon vm power-off <id>, then kyvernon vm relocate <id> --datastore <datastore>.
error.storage_move.consolidate_with_snapshots
Text in the console
The disk chain cannot be merged while the virtual machine has snapshots. Keep the chain, or remove the snapshots first.
Meaning for API clients
Merging the disk chain (consolidate) would destroy the VM's snapshots.
Cause. The move was asked to merge the disk chain into one image (chain: consolidate, or moveAllDiskBackingsAndConsolidate from a vSphere client), but the virtual machine has snapshots. Merging the chain would destroy them.
Remedy.
Move the disk with its chain: leave --chain out (it keeps the chain) or use --chain keep.
Or remove the snapshots first and then merge: kyvernon vm snapshot remove-all <id>.
error.storage_move.convert_with_chain
Text in the console
The format of disk {disk} cannot change because it has snapshots or a linked-clone base. Keep the format, or merge the chain.
Meaning for API clients
The provisioning of a disk with a snapshot chain or a linked-clone base cannot change in a move.
Cause. The move was asked to change the format of a disk (thin, thick lazy, thick eager) that has snapshots or is a linked clone. Only a disk that ends as one image can change its format.
Remedy.
Move the disk in its current format: leave --provisioning out.
Or merge the chain while moving (--chain consolidate), which needs a machine without snapshots.
error.storage_move.has_dependents
Text in the console
Disk {disk} is the base of linked clones ({dependents}). Move those first, or attach to an identical base on the target.
Meaning for API clients
The image is the base of other VMs' linked clones (dependents).
Cause. The way of moving the snapshot chain is not offered. vSphere's moveChildMostDiskBacking would leave the parents on another datastore, and createNewChildDiskBacking is an option of a clone, not of a move.
Remedy.
Use keep, share-existing or consolidate (vSphere: moveAllDiskBackingsAndDisallowSharing, moveAllDiskBackingsAndAllowSharing, moveAllDiskBackingsAndConsolidate).
error.storage_move.no_convergence
Text in the console
The copy could not keep up with the virtual machine's disk writes. Nothing changed. Raise or remove the copy rate limit, or move it when it writes less.
Meaning for API clients
The copy of a running VM's disk could not catch up with the guest's writes; the VM stays on its old disks.
Cause. The copy of a running machine's disk could not catch up with the guest's writes, even with the guest's writes slowed down to the floor. Nothing changed: the machine runs on its old disks. A copy rate limit below the machine's write rate leads here.
Remedy.
In the console, open the summary of the virtual machine, select Change limit on the card Storage migration and enter a higher limit or 0 for no limit. For a new move, change Limit the copy rate (MiB/s) under Advanced options in the wizard.
With the CLI, raise or remove the copy rate limit: --max-bandwidth on kyvernon vm relocate, or kyvernon vm relocation-limit <id> --max-bandwidth 0 while a move runs.
Move the machine when it writes less, or power it off and move it then.
error.storage_move.switchover_timeout
Text in the console
The switch to the new disks took too long and was undone. The virtual machine continues on its old disks.
Meaning for API clients
The switch to the new disks did not finish within switchover_max_ms; the VM continues on its old disks.
Cause. The final switch to the new disks, during which the guest's disk requests wait, did not finish within the allowed time (2 seconds by default). It was undone: the machine continues on its old disks and nothing changed.
Remedy.
Start the move again; a burst of writes during the switch is the usual reason.
When it happens again, check the target datastore's latency, or move the machine when it writes less.
error.storage_move.target_io
Text in the console
The target datastore failed or stopped answering during the copy. The virtual machine stays on its old disks.
Meaning for API clients
The target datastore failed or stopped answering during the copy; the VM stays on its old disks.
Cause. The target datastore failed, ran full or stopped answering while the disks were copied. The machine's own disk requests never wait for the target, so it kept running on its old disks; the copies were removed.
Remedy.
Check the target datastore: its free space (kyvernon datastore refresh <datastore>) and, for NFS or iSCSI, the storage server and the network path.
Start the move again when the datastore answers.
error.storage_move.vm_stopped
Text in the console
The virtual machine stopped during the move of its disks. Nothing changed. Move it again while it is powered off.
Meaning for API clients
The VM stopped during a move of its running disks; nothing changed. Move it again while it is powered off.
Cause. The virtual machine was powered off, stopped by its guest, or crashed while the disks of the running machine were copied. The move was undone; nothing changed.
Remedy.
Move the machine now, while it is powered off: kyvernon vm relocate <id> --datastore <datastore>.
Or power it on and start the move again.
error.storage_move.interrupted
Text in the console
The move was interrupted on the host. It is finished or undone automatically when the host is back.
Meaning for API clients
The move was lost with the VMM or the host's state; it is undone or finished from the files.
Cause. The host lost the move: its agent restarted without its records, or the hypervisor process of the machine ended during the copy. Before the switch to the new disks the move is undone; after the switch it is finished. The controller does this by itself as soon as the host answers.
Remedy.
Wait until the host is connected again. The move is then finished or undone; kyvernon vm relocation <id> shows it as being finished after an interruption.
If neither the old nor the new disk files are complete, the move stays open and needs an administrator. Contact support with the id of the virtual machine.
error.storage_move.source_io
Text in the console
A file of the disk could not be read on the source datastore ({path}). Nothing changed. Check the source datastore and move again.
Meaning for API clients
A file of the disk could not be read on the source datastore during the copy; nothing changed.
Cause. A file of the disk could not be read on the source datastore while it was copied: the storage reported a read error or stopped answering. The move ended before its switch; the virtual machine is unchanged and the copies were removed.
Remedy.
Check the source datastore: the health of its disks and, for NFS or iSCSI, the storage server and the network path. The path argument names the file.
Start the move again when the datastore reads normally. When the file itself is damaged, restore the disk from a backup first.
error.storage_move.not_switched
Text in the console
The move has not switched to the new disks yet, so the old files cannot be deleted.
Meaning for API clients
The move has not reached its switch (and its verification) yet, so its old files cannot be deleted.
Cause. The host was asked to delete the old files of a move that has not switched to the new disks yet, or whose verification has not ended. The controller asks only after the switch, so this points to an interrupted or repeated request.
Remedy.
Follow the move: kyvernon vm relocation <id>. The old files are deleted by the move itself once the switch and the verification are done.
error.storage_move.unknown_job
Text in the console
The host does not know this storage migration. It is finished or undone from the files when the controller checks.
Meaning for API clients
The host does not know the storage migration job (it ended and was forgotten, or the host lost its records).
Cause. The host does not know the storage migration job the controller asked about. It finished and was forgotten, or the host lost its records (its state directory was replaced).
Remedy.
In most cases nothing: the controller decides from the files which disks are current and finishes or undoes the move.
If kyvernon vm relocation <id> still shows the move after a few minutes, check that the host is connected: kyvernon inventory host <host>.
error.storage_move.rolled_back
Text in the console
The virtual machine was returned to its old disks after a failed verification. The new disks were deleted; writes since the switch are lost.
Meaning for API clients
The administrator returned the VM to its old disks after a failed verification; the new disks were deleted and the writes since the switch are lost.
Cause. After the verification of a storage migration failed, an administrator chose to return the virtual machine to its old disks (returnToSource). The machine was powered off, its records point at the old files again and the new disks were deleted. Everything the guest wrote since the switch is lost.
Remedy.
Power the virtual machine on again: kyvernon vm power-on <id>.
Check both datastores before you move the machine again: the failed verification points to a fault of the storage.
error.storage_move.cancelled
Text in the console
The storage migration was cancelled before the switch. Nothing changed.
Meaning for API clients
The storage migration was cancelled before its switch; nothing changed.
Cause. The storage migration was cancelled before its switch to the new disks. Nothing changed: the virtual machine uses its old disks and the copies were removed.
Remedy.
Start the move again when you want it: kyvernon vm relocate <id> --datastore <datastore>.
error.storage_move.verify_failed
Text in the console
The new disks could not be verified. The old files are kept until you choose to keep the new disks or to return to the old ones.
Meaning for API clients
A copied file or block does not match its source. The old files are kept; an administrator keeps the new disks or returns to the old ones.
Cause. After the switch to the new disks, the comparison with the old files found a block that differs and could not be repaired from the old file, or a copied file's checksum did not match. This points to a fault of the storage. The old files are kept, the alarm alarm.vm.storage_move.verify is raised, and the move waits for a decision.
Remedy.
Look at the event of the virtual machine for the counts and check the health of both datastores.
In the console, open the summary of the virtual machine. The card Storage migration offers Keep the new disks, which keeps the new disks and deletes the old files, and Power off and return to the old disks, which powers the machine off and returns to the old disks. The writes since the switch are lost when you return.
With the CLI, keep the new disks and delete the old files: kyvernon vm relocation-resolve <id> --action keep-target.
Or power the machine off and return to the old disks: kyvernon vm relocation-resolve <id> --action return-to-source.