GitHub user bernardodemarco added a comment to the discussion: VM migration
from vmware to kvm failed.
Hello, @nemethga, and others
> Where can I find a more detailed description of the functionality of
> individual parts of the migration tool?
> What should be the correct settings on the vcenter side?
> What services must be running on vcenter?
> I found out that the error could be related to the running of the vmware-sps
> service on the server?
The ACS native feature of importing VMs from VMware has some prerequisites that
must be met before starting to use it. First, the Management Servers must be
able to communicate with vCenter where the VMs are converted from, and vCenter
must have access to one of the storage systems registered in ACS (secondary
storage is a great choice; the reason is explained below). Additionally, some
packages must be installed on the KVM hosts in the compute plane, including:
- `virt-v2v`: used to perform the conversion;
- `nbdkit`: required for `virt-v2v` to perform conversions on Ubuntu hosts;
- `virtio-win`: required for Windows VM conversions to enable `virt-v2v` to
automatically install VirtIO drivers on the VMs.
With the packages installed on the KVM hosts in the compute plane, the
conversion can be performed through the graphical interface by navigating to
`Tools > Import-Export Instances` and selecting `Migrate existing instances to
KVM`. This process can be executed while the VM is running, but it is
recommended to shut it down to avoid inconsistencies in the converted VM. For
example, Windows VMs will not boot properly if converted while powered on. The
process executed by ACS is as follows:
1. The Management Server sends a command to vCenter to export the VM's OVF to
temporary storage. This storage must use NFS and be accessible to vCenter, the
KVM hosts, and the Management Servers. Therefore, one can use the secondary
storage as the temporary storage (default option if no temporary storage is
specified);
2. A KVM host runs `virt-v2v` to convert the OVF into a KVM VM;
3. The resulting KVM VM (volumes) is moved to the target primary storage; the
VM on KVM is stopped during this process;
4. The resulting KVM VM is imported into ACS (the original VM continues to
exist in VMware and remains registered in ACS, if previously registered).
**Notes:** This process is **extremely time-consuming**, making its use
**unfeasible in most use cases** when handling migration of TiB of volumes.
This happens because `virt-v2v` creates a temporary VM to inspect the source VM
and generate a converted volume with the drivers properly installed.
Additionally, volumes must be copied to temporary storage and then to the
target primary storage. Therefore, if timeouts occur with very large volumes,
the global setting `convert.vmware.instance.to.kvm.timeout` should be
increased. In case of failure, temporary volumes are automatically removed.
Additionally, the conversion itself is performed by an external tool
(`virt-v2v`), which supports most operating systems, but not all. Therefore,
conversion success depends on whether `virt-v2v` works correctly for the
operating system of the VM being converted.
---
> I do not know how it is usable in a production environment
As previously mentioned and explained, given that it takes an expressive amount
of time to migrate a VM using the built-in ACS functionality, it becomes
unusable for some production situations. However, as a workaround, manual
processes can be designed and executed to perform the migration of the
instances.
Next, a feasible alternative is described that only generates a single downtime
of a few seconds for the imported VMs. It requires a shared NFS appliance
accessible by VMware and KVM hosts, which does not need to be presented to ACS.
Basically, the approach leverages: (i) the possibility provided by QEMU of
having QCOW2 volumes with VMDK volumes as backing files; and (ii) the KVM's
functionality of consolidating the backing file of a volume into its delta
while the VM is running (the original/backing file is not changed and is kept
after the operation).
Below are the steps that could be performed to manually migrate a VM from
VMware to KVM using this approach:
1. Create and start a new VM in ACS with the same definitions as the original
VM from VMware (CPU, memory, NICs, disks, controllers, and so on);
2. Stop the new VM in ACS;
3. Collect the information about the storage and primary storage volume's path
of the new VM's volumes;
4. Migrate the original VM volumes (VMDKs) on VMware to the NFS shared between
VMware and KVM;
5. Then, we map the original VM's volume paths with the new VM's volume paths;
6. For each volume, prepare the `qemu-img` command to create a volume with a
backing file (`qemu-img create -b <volume-path-of-vm-on-vmware> -F vmdk
<volume-path-of-vm-on-kvm> -f qcow2 <volume-virtual-size>`);
- Note that at this moment, **one should only prepare the commands**;
**they must not be executed**.
7. Stop the original VM on VMware;
8. Execute the commands prepared in step 6 on a KVM host that has access to the
NFS shared between VMware and KVM and the primary storage where the new VM's
volumes are allocated;
9. Start the new VM through ACS, on the host where the commands were executed;
10. On the KVM host, list the VM's block device labels with the command `virsh
domblklist <vm-internal-name>`;
11. For every device label (except CD-ROMs), execute the command `virsh
blockpull --domain <vm-internal-name> --path <device-label>`.
With that, the downtime will only occur during the execution of steps 7 and 8,
whose commands should not take more than a few seconds to finish. With step 11,
the volumes are fully converted to QCOW2 without any downtime, ending the
import procedure. This will also make sure that the data between ACS VM and
VMware is the same, thus avoiding the need to further sync the data.
---
Hope it helps :),
Bernardo De Marco Gonçalves (bernardodemarco)
GitHub link:
https://github.com/apache/cloudstack/discussions/12888#discussioncomment-16489341
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
