Migrates virtual machines at scale to Kubernetes KubeVirt. Migrations are performed in a few simple steps, first by providing source and destination credentials, then mapping the source and destination infrastructure and creating a choreographed plan, and finally, executing the migration effort.

• Warm migration using Change Block Tracking/Incremental Backup to reduce the downtime, supported in VMware and oVirt migrations.
• For VMware migrations, the Forklift uses virt-v2v guest conversions which installs the virtio drivers and edits the guest to run on QEMU-KVM.
• Migrating to remote clusters, user can install the Forklift on one cluster and orchestrate other cluster to do the migration.
• Migrating VMs between clusters using the KubeVirt Export API.
• Validations of the Virtual Machines to let users know if migration plan has issues that need to be addressed before running.

Deploy the Forklift operator index to the cluster.

For single-architecture deployment (development):

make deploy-operator-index PLATFORM=linux/amd64 REGISTRY_TAG=latest

For multi-architecture deployment (production):

make deploy-operator-index-multiarch REGISTRY_TAG=latest

Custom build of the controller, bundle and index which will be deployed to the cluster

export REGISTRY_ORG=user
make push-controller-image \
     push-operator-bundle-image \
     push-operator-index-image \
     deploy-operator-index

Note: The order of targets is important as the bundle needs to be created after controller and index after bundle.

For information about building images for multiple architectures (AMD64, ARM64) and creating multi-arch manifests, see the Cross-Platform Build Support enhancement document.

All commits must include one of these formats in the commit description (the body of the commit message):

Primary format: Resolves: MTV-<number>

Example commit:

Subject: Fix bug in data processing
Description: Resolves: MTV-123

Exclusion format: Resolves: None

Example commit:

Subject: Update documentation
Description: Resolves: None

Chore commits: Any commit containing "chore" in the message (case insensitive) is automatically skipped.

Example chore commits:

chore: update dependencies
CHORE: clean up build files
Update dependencies and chore tasks

Note: The commit description validation is enforced via a GitHub Action that runs on all branches for push and pull request events. The validation automatically skips:

• Bot users (dependabot, renovate, ci, github-actions, etc.)
• Commits containing "chore" in the message (case insensitive)

You can validate commit messages locally using the provided script or Makefile targets:

Using Makefile targets:

# Validate the latest commit
make validate-commits

# Validate a range of commits
make validate-commits-range RANGE="HEAD~5..HEAD"

Using the script directly:

# Validate the latest commit
./scripts/validate-commits.sh

# Validate a range of commits
./scripts/validate-commits.sh --range HEAD~5..HEAD

# Validate with verbose output
./scripts/validate-commits.sh --verbose

# Get help
./scripts/validate-commits.sh --help

For comprehensive information about commit message formatting, supported issue tracking systems, and troubleshooting, see COMMIT_MESSAGE_GUIDE.md.