Improve VM import from external sources

Project LXD
Status Implementing
Author(s) @dinmusic
Approver(s)
Release
Internal ID LX065

Abstract:

We propose an extension to the LXD server that will allow the lxd-migrate tool and LXD UI to support additional VM image formats when importing an instance into LXD. Currently, only raw disk images can be imported. Our goal is to include support for VMDK (Virtual Machine Disk) and QCow2 (QEMU copy-on-write) formats. This will involve integrating image conversion on the server side, to enable various clients (particularly the LXD UI) to seamlessly support instance imports. Additionally, we aim to streamline the import process for Windows virtual machines by automating the installation of required drivers during import.

Rationale:

Expanding the lxd-migrate tool to support multiple virtual machine import formats, including VMDK and QCow2, will significantly increase its utility.
Automating the installation of necessary drivers during the migration process will further streamline the workflow and make the tool more user-friendly and efficient.

Specification

Background

The current iteration of the lxd-migrate tool is limited to importing raw disk image formats. This limitation requires users to convert their disk images to the raw format before importing them into LXD.

For Windows disk images that originate from different hypervisors (other than QEMU/KVM), it is essential to install the virtio-win driver beforehand. This process currently requires users to manually download the necessary drivers and use the virt-v2v tool, which installs those drivers during disk image conversion.

We have also observed that some older Linux distributions have virtio drivers present but not in the initramfs, which leads to boot issues after instance is imported. Utilizing the virt-v2v tool for conversion to raw format can effectively resolve this problem by rebuilding drivers into the initramfs.

To address the above issues and improve the user experience when importing instances to LXD, we plan to convert any imported disk image (except for raw format) using a virt-v2v tool once the image is uploaded to the server.

Import Workflow

The import process in LXD involves transferring the disk image to the LXD server’s backups directory. The storage.backups_volume setting allows specifying a storage pool for this transfer. If set, the transferred disk image will be stored in a volume on the chosen storage pool.

Upon successful transfer, the image operating system type is extracted using virt-v2v-inspector. If the detected operating system is Windows, LXD server will ensure that all requirements are satisfied before the disk conversion. Windows requires the virtio-win package, which will be downloaded and cached as an ISO image. Additionally, rhsrvany.exe and pvvxsvc.exe (from project https://github.com/rwmjones/rhsrvany) are required to run Windows applications as services. Those will be embedded into the LXD Snap package and made available during any migration.

Finally, regardless of the operating system type, the image will be converted using virt-v2v tool to raw disk format. Conversion will happen in-place, which means that the original image will be modified. The resulting raw disk image is then attached to the new instance as a root disk.

Packaging Changes:

LXD Snap

Snap package will be extended with virt-v2v tool, and rhsrvany.exe and pvvxsvc.exe files that are required when importing Windows images.

API Changes:

  • None

CLI Changes:

  • None

Database Changes:

  • None

Upgrade Handling:

  • None
2 Likes

We can clarify this section that virt-v2v will take the virtio drivers from the guest and rebuild them into the initramfs to allow booting.

How about this:

We propose an extension to the LXD server that will allow the lxd-migrate tool and LXD UI to support additional VM image formats when importing an instance into LXD.

1 Like

This is true, but virt-v2v wont help with that. The scenario where virt-v2v will help with is where the guest has virtio drivers present but not in its initramfs.

We should still use virt-v2v tool even if its raw in case the guest needs any modification for its virtio drivers.

1 Like

Can you mention here that this allows using the storage.backups_volume setting to store temporary uploads in a volume on a storage pool too.

We need to check how this is done to ensure that we dont try and mount the guest on the host.

Great job, Din!

Tom’s point about checking if we mount guest’s filesystems on the host is really interesting. If I don’t miss anything all the guest’s filesystems should be mounted inside the temporary QEMU VM that virt-v2v creates. But we need to check that. The easiest way to do that is to take a look into the virt-v2v logs (with the verbose mode turned on).

2 Likes

@tomp Thanks for the comments, I’ve improved the spec accordingly.

@amikhalitsyn As you have pointed out, all the guest’s filesystems are mounted within a temporary QEMU VM, even during the inspection of the image.

1 Like