Common questions and answers about using Hyper2KVM for VM migration.
Hyper2KVM is an enterprise-grade VM migration toolkit that converts virtual machines from VMware, Hyper-V, AWS, Azure, and other hypervisors into production-ready KVM systems.
Key Features:
See: Main Documentation
Unlike traditional migration tools that “boot and hope,” Hyper2KVM applies deterministic offline fixes to ensure first-boot success:
| Feature | virt-v2v | Other Tools | Hyper2KVM |
|---|---|---|---|
| Offline Fixes | Limited | None | Comprehensive |
| Windows VirtIO | Manual | Manual | Automatic |
| fstab Repair | Basic | None | Advanced |
| Initramfs Rebuild | No | No | Yes |
| XFS UUID Fix | No | No | Yes |
| Batch Migration | Limited | Limited | Full |
| Native Python | No (C) | Varies | Yes |
| Kubernetes | No | No | Yes |
Key Differentiator: VMCraft - Native Python VM manipulation engine with 480+ APIs.
Yes! Hyper2KVM v2.1.0+ is production-ready:
✅ Tested:
✅ Platforms:
✅ Enterprise Features:
See: Test Results
Source Hypervisors:
Guest Operating Systems:
Output Formats:
See: OS Support
Short Answer: Depends on method
Methods:
See: Migration Playbooks
Quick Install:
# Full installation (recommended)
pip install "hyper2kvm[full]"
# Minimal installation
pip install hyper2kvm
# From source
git clone https://github.com/ssahani/hyper2kvm.git
cd hyper2kvm
pip install -e ".[full]"
Verification:
h2kvmctl --version
hyper2kvm --version
See: Installation Guide
Minimum:
Recommended:
See: System Requirements
Yes, most operations require root/sudo.
Why:
Usage:
# Run with sudo
sudo h2kvmctl --config migration.yaml
# Or use sudo -i
sudo -i
h2kvmctl --config migration.yaml
Security: See Security Best Practices
Yes! Multiple options:
podman run -d -v /data:/data \
ghcr.io/ssahani/hyper2kvm:2.1.0-worker
helm install hyper2kvm-operator ./helm/hyper2kvm-operator
# Via OperatorHub or Helm
See: Container Deployment Guide
Typical Times:
| VM Size | OS Type | Time |
|---|---|---|
| <20 GB | Linux | 3-5 min |
| <20 GB | Windows | 5-8 min |
| 20-50 GB | Linux | 8-15 min |
| 20-50 GB | Windows | 12-20 min |
| >50 GB | Linux | 20-40 min |
| >50 GB | Windows | 30-60 min |
Factors:
See: Performance Metrics
Yes! Full Windows support including:
✅ VirtIO Driver Injection
✅ Supported Versions:
✅ Features:
Example:
command: local
vmdk: /vmware/windows-server-2019.vmdk
output_dir: /kvm/vms
to_output: windows-server.qcow2
# Windows-specific
windows_drivers: true
Yes, but requires multiple migrations:
# Disk 1 (boot disk with fixes)
sudo hyper2kvm --config << EOF
command: local
vmdk: /vmware/vm-disk1.vmdk
output_dir: /kvm/vms
to_output: vm-disk1.qcow2
fstab_mode: stabilize-all
regen_initramfs: true
update_grub: true
EOF
# Disk 2 (data disk, no fixes needed)
sudo hyper2kvm --config << EOF
command: local
vmdk: /vmware/vm-disk2.vmdk
output_dir: /kvm/vms
to_output: vm-disk2.qcow2
compress: true
EOF
Then update libvirt XML to include both disks.
See: Recipe #10
Yes, using live-fix method:
command: live-fix
host: esxi-host.example.com
user: root
identity: ~/.ssh/id_rsa
# Fixes
fstab_mode: stabilize-all
regen_initramfs: true
update_grub: true
Process:
See: Migration Playbooks
Yes! Multiple methods:
Method 1: JSON Manifest
command: local
batch_manifest: migrations.json
batch_parallel: 3
output_dir: /kvm/batch
{
"migrations": [
{"vmdk": "/vmware/vm1.vmdk", "to_output": "vm1.qcow2"},
{"vmdk": "/vmware/vm2.vmdk", "to_output": "vm2.qcow2"},
{"vmdk": "/vmware/vm3.vmdk", "to_output": "vm3.qcow2"}
]
}
Method 2: Kubernetes Operator
Submit multiple MigrationJob CRDs.
Input Formats:
Output Formats:
See: CLI Reference
Partial Support:
BitLocker (Windows):
LUKS (Linux):
Workaround:
# 1. Decrypt on source
# Windows: Disable BitLocker
# Linux: cryptsetup luksClose
# 2. Migrate
sudo hyper2kvm --config migration.yaml
# 3. Re-encrypt on target
# Windows: Enable BitLocker
# Linux: cryptsetup luksFormat
VMware Snapshots:
Process:
# In VMware
1. Right-click VM → Snapshots → Consolidate
2. Wait for consolidation
3. Export VM or migrate VMDK
See: VMDK Inspector
Yes, supported:
Source:
Output:
Example:
# Sparse output (saves space)
compress: true
keep_sparse: true
# Preallocated output (better performance)
preallocate: true
compress: false
Problem: VM doesn’t boot after migration
Common Causes:
Solution:
command: offline-fix
qcow2: /kvm/vms/failed-boot.qcow2
# Comprehensive fixes
fstab_mode: stabilize-all
regen_initramfs: true
initramfs_add_drivers:
- virtio
- virtio_blk
- virtio_scsi
- virtio_net
update_grub: true
Problem: No network connectivity after migration
Common Causes:
Solution:
command: offline-fix
qcow2: /kvm/vms/no-network.qcow2
# Network fixes
regen_initramfs: true
initramfs_add_drivers:
- virtio_net
- e1000
fstab_mode: stabilize-all
Manual Fix:
# Inside VM after boot
ip link # Check interface name
nmcli device # Check NetworkManager
Problem: Migration fails with error
Common Errors:
# Solution: Run with sudo
sudo hyper2kvm --config migration.yaml
# Check available space (need 3x VM size)
df -h /output/directory
# Install required tools
sudo dnf install -y qemu-img qemu-system-x86 # RHEL/Fedora
sudo apt-get install -y qemu-utils # Ubuntu
# Validate VMDK first
./scripts/vmdk_inspect.py /path/to/vm.vmdk
If migration fails or VM doesn’t work:
Option 1: Keep Original
Option 2: Use Snapshots
# Before migration
qemu-img snapshot -c before_migration vm.qcow2
# Rollback if needed
qemu-img snapshot -a before_migration vm.qcow2
Option 3: Backup
# Before migration
cp /vmware/original.vmdk /backup/original.vmdk.backup
See: Migration Playbooks
Can’t find your question? Ask on GitHub Discussions
Last Updated: February 2026
Total Questions: 25+
Coverage: Installation, Migration, Troubleshooting, Technical