Known Limitations

This page documents known limitations, unsupported configurations, and important caveats in vJailbreak. Review this page before planning a migration to avoid unexpected failures.

Windows Dynamic Disk (LDM)

Windows VMs that use dynamic disks (Logical Disk Manager / LDM) cannot be migrated directly. virt-v2v fails during the inspection phase when the Windows boot disk uses LDM volumes.

Workaround: Before migrating, boot the VM in VMware and convert dynamic disks to basic disks using diskpart:

diskpart
select disk N
convert basic

If the disk contains data, back it up first. See the full troubleshooting guide: Windows Dynamic Disk (LDM) migration issue.

Configuration	Result
Root: Basic, Data: LDM	Works — import LDM disks in Windows post-migration
Root: LDM, Data: Basic	Fails — must convert root disk to basic
Root: LDM, Data: LDM	Fails — must convert root disk to basic

Active Directory-Joined VMs

Domain Controllers

Migrating Active Directory Domain Controller VMs is strongly not recommended. The core risk is specific to how vJailbreak works: virt-v2v performs a disk-level conversion and creates a new VM on a different hypervisor. VM-GenerationID — the hypervisor metadata that Windows Server 2012+ uses to detect unsafe restores — is not stored on disk and is not preserved through this process. The migrated DC starts with a new (or absent) VMGenID, which Windows AD treats as an unsafe restore/clone.

What happens depends on the Windows version:

• Windows Server 2012 and later: The lost VMGenID triggers Windows’ built-in safeguards. The DC automatically resets its invocation ID and forces a non-authoritative resync against replication partners. The domain may recover if other DCs are reachable, but this is unreliable in production and is not a supported migration path.
• Windows Server 2008 R2 and earlier (no VMGenID support): A genuine USN rollback can occur. The domain silently stops accepting replication from the migrated DC, and the AD environment can diverge without obvious errors. This is difficult to detect and hard to recover from.

In both cases the source DC must be permanently removed from the domain before or immediately after the migrated copy is brought online. Running both simultaneously on the same domain will corrupt AD.

Recommended approach (from Microsoft guidance):

1. Provision a new DC in the target OpenStack environment using standard AD promotion.
2. Let AD replication populate it from an existing domain controller.
3. Decommission the source DC via dcpromo or Server Manager once replication is verified complete.

If you must migrate a DC (lab/test environments, single-DC setups with no alternative), take these precautions:

• Cleanly shut down the source DC before migration — do not snapshot a running DC.
• Migrate only one DC at a time.
• After the migrated DC boots, verify replication health immediately:

  repadmin /replsummary
  dcdiag /test:replications

• Confirm time synchronization (Kerberos requires clocks within 5 minutes of each other).
• Verify DNS is resolving correctly for all domain members.
• Decommission the source DC immediately — never run the original and migrated DC on the same domain simultaneously.

Member Servers and Workstations

Migrating domain-joined member VMs (non-DC servers and workstations) is generally safe. The machine account password is stored in the VM’s own LSA secrets and is copied with the disk, so domain membership typically survives the migration intact.

A few edge cases can cause domain authentication to fail post-migration:

• Kerberos clock skew: If the migrated VM’s clock is more than 5 minutes off from the domain controller, Kerberos authentication will fail. Sync the VM’s clock immediately after boot.
• DNS resolution failures: The VM must be able to resolve the domain controller’s name and locate AD SRV records. Verify DNS settings after migration.
• Pre-existing stale computer account: If the source VM had been offline for an extended period (typically 90+ days) before migration, the domain controller may have already invalidated its computer account. This is a pre-existing condition unrelated to the migration itself.

If users see The trust relationship between this workstation and the primary domain failed after migration, run the following to reset the account:

# Option 1 — reset computer account password without rejoining
netdom resetpwd /server:<domain-controller> /userd:<domain\admin> /passwordd:*

# Option 2 — rejoin the domain
Remove-Computer -WorkgroupName WORKGROUP -Force
Add-Computer -DomainName <domain> -Credential <domain\admin> -Restart

Persist Network: Windows Server 2012 and Below

The Persist source network interfaces option does not work for Windows Server 2012 and earlier (including Windows Server 2008 R2 and Windows Server 2008).

Network interface name persistence depends on PowerShell capabilities, the Windows registry structure for network adapters, and a compatible version of pnputil. These prerequisites are not met on Windows Server 2012 and earlier.

Workaround: Manually reconfigure network interface names and static IP settings inside the VM after migration.

Assign IP and Persist Network Cannot Be Used Together

The Assign IP and Persist Network (Persist source network interfaces) options are mutually exclusive. Enabling both simultaneously produces undefined behavior and the migration may not apply either setting correctly.

Rule: Use one or the other — not both.

• Use Assign IP when you need to set a specific IP address on the destination VM.
• Use Persist Network when you need to preserve the source VM’s interface names and static routes.

Multi-IP Assignment Not Supported

Only one IP address per network interface is supported in the Assign IPs field. The UI enforces this — the field accepts a single IP per interface. If multiple IPs are specified via CLI, the migration will fail.

Workaround: Assign additional IPs manually inside the VM after migration, or use OpenStack port configuration to attach additional floating IPs post-migration.

VMware Tools Removal: Residual Artifacts

The VMware Tools removal process performed by virt-v2v during migration may leave behind residual files and registry entries on the destination VM.

These artifacts are typically harmless but may appear in application logs or security scans.

For a full list of known residual artifacts and cleanup steps, see: VMware Residual Artifacts.

Multi-Boot VMs Not Supported

vJailbreak does not support VMs with multiple bootable operating systems (multi-boot configurations). virt-v2v inspects only a single OS installation per VM and cannot convert multi-boot disk layouts.

Workaround: Migrate each OS as a separate VM, or convert the disk to a single-boot configuration before migration.

Hotplug Flavor Requirements

OpenStack hotplug (live CPU/RAM resize without VM reboot) is supported post-migration, but only if the assigned flavor is explicitly configured for hotplug by the OpenStack administrator.

To use hotplug after migration:

1. Ask your OpenStack admin to create a flavor with hotplug-enabled extra specs, for example:

   openstack flavor set <flavor-name> \
     --property hw:cpu_policy=mixed \
     --property hw:cpu_max_vcpus=<max> \
     --property hw:mem_page_size=any

2. Assign this flavor in the vJailbreak migration form before starting the migration.

3. After migration, resize the VM in OpenStack using the hotplug-capable flavor.

Note

Standard flavors without hotplug extra specs will not support live resize. The VM must be powered off for a cold resize in that case.

Low Disk Space in the Source VM

Before starting conversion, virt-v2v checks that each filesystem inside the source VM has sufficient free space. If any filesystem is too full, the conversion fails before it begins.

Minimum free space required inside the source VM (source: virt-v2v docs):

Filesystem	Minimum free space
Linux root (/)	100 MB
Linux /boot	50 MB (needed to rebuild initramfs)
Windows C: drive	100 MB (virtio drivers and guest agents are copied in)
Any other mountable filesystem	10 MB

Each filesystem must also have at least 100 free inodes.

Workaround: Before migrating, free up space inside the source VM on any full partitions. Check with df -h (Linux) or Disk Management (Windows).

Application Reboot During Migration

Cold migration (Power off VMs, then copy) powers off the source VM before copying its disk. The destination VM boots fresh after migration completes. Applications must tolerate a reboot — any in-memory state, open transactions, or non-persistent connections will be lost.

Hot migration (Copy live VMs, then power off) minimizes downtime but still requires a brief power-off during the final cutover phase to synchronize the last changed blocks. Applications should be tested for graceful handling of this cutover reboot.

Caution

Before migrating, verify that your application starts cleanly after a cold reboot. Applications that require manual intervention to restart (e.g., databases with crash-inconsistent state) should be cleanly shut down inside the VM before initiating cold migration.