Converting from VMware to OpenStack
When restoring a VMware virtual machine from backup, you can convert the VM to an OpenStack instance.
You can perform VM conversions from streaming backups, from secondary copies, or from IntelliSnap backup copies. You cannot perform a conversion from a Snap copy.
Before You Begin
- Create a virtualization client for the OpenStack hypervisor.
- Virtual machines running the following guest operating systems can be converted to OpenStack instances:
- CentOS 7
- RHEL 7
- Windows 2012 R2
- Windows 2008 R2
- Before backing up the source VMs, ensure that appropriate drivers are available:
- For Windows VMs, if the source VM has more than four disks, install VirtIO drivers on source VMs, to ensure that the instance will be bootable after conversion.
- For UNIX flavors that do not include VirtIO drivers, install VirtIO drivers on source VMs. By default, RHEL 7.0 and CentOS 7.0 have VirtIO drivers pre-loaded.
- Before converting a Linux VM: If the source VM contains a device entry in etc/fstab in the following format:
/dev/device_name mountpoint fs_type mount_args
change the entry in the source VM to use the following format instead:
UUID=fs_uuid mountpoint fs_type mount_args
You can run the lsblk -f command on the source VM to return a list of the UUIDs for block devices in the source VM.
- To convert a VM with more than four disks, libvirt version 1.3.3 or later is required on the destination Nova compute nodes for the converted OpenStack instance.
Red Hat Bug 1343302 reports an issue with attaching more volumes for earlier libvirt versions.
- Perform a full VM backup of the VMware (source) virtual machines.
- To specify the administrator (root) user password for each instance to utilize upon restore, complete the following steps prior to running the restore operation:
- To your /etc/nova/nova.conf file, add the line:
inject_password=true. For more information, see OpenStack: Injecting the Administrator Password.
- To the CommServe computer, add the bEnableOpenstackAdminPwd additional setting as shown in the following table.
For instructions on adding additional settings from the CommCell Console, see Add or Modify an Additional Setting.
- To your /etc/nova/nova.conf file, add the line:
- If an instance or image is added to subclient content or to a filter by browsing and selecting the display name, discovery is performed based on the GUID for the instance or image. If that instance or image is later restored in place from a backup, a new GUID is generated, and that instance or image is no longer identified correctly. To identify that instance or image, you must remove the old rule, then add a new rule or use a name pattern to select the instance or image.
- If the user specified for the virtualization client does not have permission to create or delete network ports, the restore fails. See VOPS0002: Restore fails with error "Failed to create port with request".
Conversion includes the following stages:
- Obtain disk information from the VMware backup, mark disk sizes, and identify any operating system disk (bootable disk).
- Identify the operating system and collect configuration information such as CPUs, memory, and NIC information that can be used as context for the restore destination.
- Create cinder volumes based on the source volume types, attach the volumes to the VSA proxy, and restore the volumes.
- All disks from the VMware backup are converted to cinder volumes.
- If the source VM contained up to four virtual machine disks, the VM conversion sets flags on the cinder volume to direct OpenStack to add the volumes to an IDE controller
- If the source VM contained more than four virtual machine disks, the VM conversion sets flags on the cinder volume to direct OpenStack to add the volumes to a VirtIO controller.
- For volumes added to a VirtIO controller, up to 25 data volumes can be attached to the VSA proxy. This limit includes any volumes already attached to the proxy. For example, if a proxy already has two volumes attached, then only 23 data volumes can be attached.
- Create an instance from a volume based on the flavor and other conversion options selected for the conversion.
The flavor determines the number of CPUs and memory, and other conversion settings control the access to the instance, network settings, security groups, and the destination zone, region, tenant , or host.
- Launch an instance using the cinder volume marked as OS/bootable.
The rest of the volumes are attached after the instance is running.
- Volumes attached to the proxy during the conversion are detached for cleanup.
- From the CommCell Browser, expand Client Computers > virtualization_client > Virtual Server > VMware > backup_set.
- Initiate the restore from a subclient or backup set:
- From a subclient: Right-click the subclient and then select Browse and Restore.
- From a backup set: Right-click the backup set, point to All Tasks, and click Browse and Restore.
- In the Browse and Restore Options dialog box, ensure that Full Virtual Machine is selected.
- From the Restore as list beside Full Virtual Machine, select Openstack.
- Click View Content.
- From the list of backed up instances, select one or more virtual machines to be converted, and then click Recover All Selected.
- In the Restore Options for All Selected Items dialog box, provide the following information:
To restore to a different OpenStack keystone node, select the virtualization client from the list.
This area displays the keystone address for the selected OpenStack virtualization client and the user account specified for the virtualization client.
Select a VSA proxy in the destination data center.
The proxy can be a Windows or Linux machine.
By default, an instance or image is restored to the original location. To restore out of place, perform the following steps:
The Instance and Volume column shows information for the source instance. You can expand an instance to view volumes.
- In the Change Instance name to column, enter the new display name for the instance.
- Click in the Availability Zone column, and then click ... to browse defined availability zones and select a host.
- From the Volume type list, select a value that is appropriate for the storage to be used.
- To change other settings, select a virtual machine and click Configure.
The Openstack Instance Configuration dialog box appears. You can modify the following settings:
- Instance Display Name: Displays the destination instance name.
- Availability Zone: Click ... to browse defined availability zones and select a host. You must select a value for this option before specifying other settings.
- Flavor: Select a flavor that is at or above the original configuration. The AutoSelect option is not supported.
- Security Group (Optional): Select a predefined security group that defines the required network access.
- Key Pair (Optional): Select a key pair that identifies the ownership for the converted instance.
- Admin Password: Enter the administrator (root) user password that should be utilized for this instance upon restore.
- Confirm Password: Re-enter the administrator (root) user password that should be utilized for this instance upon restore.
- Openstack Virtual Network Options / Network Interface n: For each of the network interfaces on the source VM, click ... to select a network interface that is available in the destination.
- Click OK.
Power ON Instance after Restore
Select this check box to power on the instance automatically after the restore is complete.
Unconditionally overwrite Instance with the same name
Select this check box to overwrite any existing instances with the same names in the target location. If you do not select this check box when restoring an instance to a location that has an instance with the same name, the restore fails.
- Click OK to initiate the restore job.
After the Conversion
To enable converted UNIX guest instances to launch, select a boot option such as rescue mode, which uses an initrd with a large set of commonly used drivers.
In some cases the guest instance might enter maintenance mode and fail to start, even after selecting rescue mode. In such cases, perform the following steps on the converted guest instance:
- While in maintenance mode, run the following command to rebuild the initrd file:
mkinitrd -f -v /boot/initrd-$(uname -r).img $(uname -r)
Note: If the kernel version of the default boot option is different from the version of the rescue mode kernel, use the kernel version of the default boot option instead of $(uname -r).
- Restart the guest instance.
Note: For guest instances that do not have a rescue grub entry, perform the preceding steps on the source VM to re-create the initrd file, and then repeat the conversion.
Last modified: 2/5/2020 9:04:20 PM