LogoLogo
T4O-5.x
T4O-5.x
  • About Trilio for OpenStack
    • Welcome to Trilio for OpenStack
    • T4O Architecture
    • Release Notes
    • Compatibility Matrix
    • Resources
      • 5.2.4
      • 5.2.3
      • 5.2.2
      • 5.2.1
      • 5.2.0
      • 5.1.0
      • 5.0.0
  • Getting Started
    • Requirements
      • Network Considerations
      • Installation Strategy and Preparation
    • Getting started with Trilio on Red-Hat OpenStack Platform (RHOSP)
      • Post Installation Health-Check
    • Getting started with Trilio on Kolla-Ansible OpenStack
    • Getting started with Trilio on Canonical OpenStack
    • Software Driven Migration: VMware to OpenStack
      • Trilio's Approach
      • Supported Environments
      • Preparations
      • Deployment & Configuration
      • VM Migration Tool
      • Limitations
    • Licensing
    • Installing WorkloadManager CLI client
    • Uninstall Trilio
      • Uninstalling from RHOSP
  • Upgrading to T4O-5.x from older supported versions
    • Supported Trilio Upgrade Path
    • Upgrading on RHOSP
    • Upgrading on Kolla
    • Enabling T4O 4.1 or older backups when using NFS backup target
  • Advanced Configuration
    • Switching NFS Backing file
    • Multi-IP NFS Backup target mapping file configuration
    • Advanced Ceph configurations
      • Additions for multiple CEPH configurations
    • Multi-Region Deployments
  • User Guide
    • Workloads
    • Snapshots
    • Restores
    • File Search
    • Snapshot Mount
    • Schedulers
    • E-Mail Notifications
    • VMware migration
      • Migration Plans
        • How-to Guide: Creating a Migration Plan
      • Migrations
        • How-to Guide: Initiating a Migration
  • Admin Guide
    • Backups-Admin Area
    • Workload Policies
    • Workload Quotas
    • Managing Trusts
    • Workload Import & Migration
    • Disaster Recovery
      • Example runbook for Disaster Recovery using NFS
      • Example runbook for Disaster Recovery using S3
    • Migrating encrypted Workloads
    • Rebasing existing workloads
  • Troubleshooting
    • Frequently Asked Questions
    • General Troubleshooting Tips
    • Important log files
  • API GUIDE
    • Workloads
    • Snapshots
    • Restores
    • File Search
    • Snapshot Mount
    • Schedulers
    • E-Mail Notification Settings
    • Workload Policies
    • Workload Quotas
    • Managing Trusts
    • Workload Import and Migration
Powered by GitBook
On this page

Was this helpful?

Export as PDF
  1. Getting Started
  2. Software Driven Migration: VMware to OpenStack

Limitations

PreviousVM Migration ToolNextLicensing

Last updated 10 months ago

Was this helpful?

Trilio uses a widely used tool virt-v2v for migration which is one of the open-source tools by Red Hat. The below-mentioned limitations are from this tool and thus a limitation for Trilio as well:

  • virt-v2v cannot change the default kernel in the GRUB2 configuration, and the kernel configured in the VM is not changed during the conversion, even if a more optimal version of the kernel is available on the VM.

  • After converting a virtual machine to KVM, the name of the VM's network interface may change, and thus requires manual configuration.

  • Trilio does not support nested virtualization OpenStack deployments for VMware migration.

  • For Windows VMs, post migration all the non system disk would be in offline state. You would need to login to the guest VM and manually bring all the attached disk online, follow the below steps:

1. To bring a disk online, run command prompt as an administrator.
2. Run command diskmgmt.msc
3. Right click on the offline disk and change it to Online.
  • Windows VMs migrated with the Dry-Run type won't be bootable on OpenStack, as complete boot information won't be available until the guest VM is shut down.

Please refer to for more information.

Other Limitations specific to VM Migration:

  • If any VM is having independent (i.e. not mounted on "/") /usr partition, then migration of such VM will fail with below error:

virt-v2v: error: inspection could not detect the source guest (or physical
machine).

Assuming that you are running virt-v2v/virt-p2v on a source which is
supported (and not, for example, a blank disk), then this should not
happen.

Inspection field 'i_arch' was 'unknown'.
Post-Conversion Tasks