Skip to content

Commit 979dd6a

Browse files
Update importing_vmware_vms_into_kvm.rst
1 parent 3e17e32 commit 979dd6a

File tree

1 file changed

+17
-20
lines changed

1 file changed

+17
-20
lines changed

source/adminguide/virtual_machines/importing_vmware_vms_into_kvm.rst

Lines changed: 17 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -13,23 +13,21 @@
1313
specific language governing permissions and limitations
1414
under the License.
1515
16-
.. note:: This functionality requires **virt-v2v** (https://www.libguestfs.org/virt-v2v.1.html) binary installed on destination cluster hosts (needs to be installed manually as it's not a dependency of the CloudStack agent during the agent installation.
16+
.. note:: This functionality requires **virt-v2v** (https://www.libguestfs.org/virt-v2v.1.html) binary installed on destination cluster hosts (needs to be installed manually as it's not a dependency of the CloudStack agent during the agent installation).
1717

1818
Requirements on the KVM hosts
1919
-----------------------------
2020

21-
The CloudStack agent does not install the virt-v2v binary as a dependency. The virt-v2v binary must be installed manually on KVM hosts.
21+
The CloudStack agent does not install the virt-v2v binary as a dependency. The virt-v2v binary must be installed manually on KVM hosts, or the migration will fail
2222

23-
In case virt-v2v is not installed on a KVM host attempting a Virtual Machine conversion from VMware, the process fails.
24-
25-
The virt-v2v output (progress) is logged in the CloudStack agent logs, to help administrators track the progress on the Virtual Machines conversion processes. The verbose mode for virt-v2v can be enabled by adding the following line to /etc/cloudstack/agent/agent.properties and restart cloudstack-agent:
23+
The virt-v2v output (progress) is logged in the CloudStack agent logs, to help administrators track the progress on the Instance conversion processes. The verbose mode for virt-v2v can be enabled by adding the following line to /etc/cloudstack/agent/agent.properties and restart cloudstack-agent:
2624

2725
::
2826

2927
virtv2v.verbose.enabled=true
3028

3129

32-
Installing virt-v2v on Ubuntu KVM hosts does not install nbdkit which is required in the conversion of VMWare VCenter guests. To install it, please execute:
30+
Installing virt-v2v on Ubuntu KVM hosts does not install nbdkit which is required in the conversion of VMware VCenter guests. To install it, please execute:
3331

3432
::
3533

@@ -68,7 +66,7 @@ For Debian-based distributions:
6866

6967
apt install virtio-win (if the package is not available, then manual steps will be required to install the virtio drivers for windows)
7068

71-
The OVF tool (ovftool) must be installed on the destination KVM hosts if the hosts should import VM files (OVF) from vCenter directly. If not, management server imports them (management server is not using ovftool, so no need to install it on the management server hosts.
69+
The OVF tool (ovftool) must be installed on the destination KVM hosts if the hosts should export VM files (OVF) from vCenter. If not, the management server exportds them (the management server doesn't require ovftool installed).
7270

7371
Usage
7472
-----
@@ -95,10 +93,10 @@ Selecting the VM from a VMware Datacenter
9593

9694
CloudStack administrators must select the Source VMware Datacenter:
9795

98-
- Existing: The existing zones are listed, and for each zone, CloudStack will list if there is any VMware Datacenter associated with it. In case it is, it can be selected
99-
- External: CloudStack allows listing Virtual Machines from a VMware Datacenter that is not associated with any CloudStack zone. To do so, it needs the vCenter IP address, the datacenter name, and username and password credentials to log in to the vCenter. You can use the default datacenter name (ha-datacenter or other) along with host credentials to import from standalone VMware hosts (Only stopped VMs are supported).
96+
- Existing: The existing zones are listed, and for each zone, CloudStack will list if there is any VMware Datacenter associated with it. In case it is, it can be selected.
97+
- External: CloudStack allows listing Virtual Machines from a VMware Datacenter that is not associated with any CloudStack zone. To do so, the vCenter IP address, the datacenter name, and username and password credentials are needed to log in to the vCenter. To import from a standalone VMware host, you can use the default datacenter name (ha-datacenter or other) along with the host credentials (Only stopped VMs are supported).
10098

101-
Once the VMware Datacenter is selected, click on List VMware Instances to display the list of Virtual Machines on the Datacenter. You must then select the VMware Instance for import and click on Import Instance.
99+
Once the VMware Datacenter is selected, click on List VMware Instances to display the list of Virtual Machines in the Datacenter. You must then choose the VMware Instance for import and click on Import Instance.
102100

103101
Converting and importing a VMware VM
104102
------------------------------------
@@ -107,7 +105,7 @@ Converting and importing a VMware VM
107105

108106
.. note:: You can configure the parallel import of VM disk files on KVM host and management server, using the global settings: threads.on.kvm.host.to.import.vmware.vm.files and threads.on.ms.to.import.vmware.vm.files respectively.
109107

110-
In the UI import wizard, you can optionally select a KVM host and temporary destination storage (default is Secondary Storage, but if using Primary Storage - only NFS pools are supported) for the conversion, where VM files (OVF) will be copied to. This can be done by a random (or explicitly chosen) KVM host (if the ovftools are installed), otherwise, the management server will import/copy the VM files (optionally, you can force this action to be done by the management server even the KVM hosts have the ovftools installed in it). Irrelevant if the KVM host or the management server performs the copy of the VM files (OVF), you can further either let CloudStack choose which KVM host should do the conversion of the VM files using virt-v2v and which host will import the files to the destination Primary Storage Pool, or you can explicitly choose these KVM hosts for each of the 2 mentioned operations.
108+
In the UI import wizard, you can optionally select a KVM host and temporary destination storage (default is Secondary Storage, but if using Primary Storage - only NFS pools are supported) for the conversion, where VM files (OVF) will be copied to. This can be done by a random (or explicitly chosen) KVM host (if the ovftools are installed), otherwise, the management server will export/copy the VM files (optionally, you can force this action to be done by the management server even the KVM hosts have the ovftools installed in it). Irrelevant if the KVM host or the management server performs the copy of the VM files (OVF), you can further either let CloudStack choose which KVM host should do the conversion of the VM files using virt-v2v and which host will import the files to the destination Primary Storage Pool, or you can explicitly choose these KVM hosts for each of the 2 mentioned operations.
111109

112110
|import-vm-from-vmware-to-kvm-options.png|
113111

@@ -120,11 +118,11 @@ When importing an instance from VMware to KVM, CloudStack performs the following
120118
The existence of ovftool on KVM host is checked using
121119
``ovftool --version`` command.
122120

123-
- If the instance on VMWare is in **running** state, we clone the instance on
124-
VMWare and use the new cloned instance to export OVF files.
121+
- If the instance on VMware is in **running** state, we clone the instance on
122+
VMware and use the new cloned instance to export OVF files.
125123
The cloning process may take some time to complete and is used to ensure data consistency,
126124
disk consolidation, etc.
127-
- If the instance on VMWare is in **stopped** state, we directly use the
125+
- If the instance on VMware is in **stopped** state, we directly use the
128126
instance to export it's OVF files.
129127
- Converts the OVF on the temporary storage location to KVM using
130128
**virt-v2v**. CloudStack (or the administrator) selects a running and
@@ -139,16 +137,15 @@ When importing an instance from VMware to KVM, CloudStack performs the following
139137
temporary instance to inspect the source VM and generate the converted
140138
disks with the correct drivers. Additionally, it needs to copy the
141139
converted disks into the temporary location.
142-
- The converted instance is then imported into the chosen KVM cluster.
143-
Administraator can choose the KVM host or let CloudStack choose it. . Only enabled
144-
cluster & enabled host are considered.
140+
- The converted instance (i.e. QCOW2 files) is then imported into the chosen KVM cluster.
141+
Administrator can choose the KVM host to perform the import, or let CloudStack choose it. Only enabled
142+
cluster and enabled hosts are considered.
145143

146-
.. note:: Please consider not restarting the management servers while importing as it will lead to the interruption of the process and you will need to start again.
144+
.. note:: Please do not restart the management servers while migration is in progress as it will lead to the interruption of the process and you will need to start again.
147145

148146
.. note:: As mentioned above, the migration/conversion process uses an external tool, virt-v2v, which supports most but not all the operating systems out there (this is true for both the host on which the virt-v2v tool is running as well as the guest OS of the instances being migrated by the tool). Thus, the success of the import process will, almost exclusively, depend on the success of the virt-v2v conversion. In other words, the success will vary based on factors such as the current OS version, installed packages, guest OS setup, file systems, and others. Success is not guaranteed. We strongly recommend testing the migration process before proceeding with production deployments.
149147

150-
.. note:: The resulting imported VM uses the default Guest OS type: **CentOS 4.5 (32-bit)**.
151-
After importing the VM, please Edit the Instance to change the Guest OS Type accordingly.
148+
.. note:: The resulting imported VM uses the default Guest OS type: **CentOS 4.5 (32-bit)**. After importing the VM, please Edit the Instance to change the Guest OS Type accordingly.
152149

153150
.. |import-vm-from-vmware-to-kvm.png| image:: /_static/images/import-vm-from-vmware-to-kvm.png
154151
:alt: Import VMware Virtual Machines into KVM.

0 commit comments

Comments
 (0)