Importing KVM Servers
Introduction
Although no import methods exist yet from competing virtualization solutions, it's still possible to migrate data in to VirtFusion.
VirtFusion uses the industry standard cloud-init and guest agent (if available) to provision and manage virtual servers, however a large portion of competing products use invasive methods at hypervisor level to achieve the same result. This means virtual servers imported in to VirtFusion will need extra packages if you want to take full control.
This guide will help you install those dependencies and move virtual disks in to VirtFusion.
This guide presumes you are migrating virtual machines from an existing hypervisor with virtual machines to a newly installed VirtFusion hypervisor.
Disk Preparation
Disks come in all shapes, sizes and locations and differ in type (qcow2, raw and LVM).
Dependant on the software you are using, the location of the disk could be anywhere on the hypervisor filesystem, you'll need to find the location of the disk before you can continue.
ALL DISK ACTIONS SHOULD BE COMPLETED WITH THE VIRTUAL SERVER IN AN OFFLINE STATE.
One of the most important parts of migrating a disk, is making sure you know the size and type of the disk you are going to import. If you don't do this, it may cause data corruption and inaccurate statistics in Virtfusion.
LVM
If your disks are stored in logical volumes, you will need to convert them to images. You can convert to disk images easily using the following commands:
/dev/vg_name/lv_name should be the path to the volume that contains the virtual server data and /path/to/disk.img will be the output disk image.
Convert to Qcow2 Image
qemu-img convert -O qcow2 /dev/vg_name/lv_name /path/to/disk.img
Convert to Raw Image
qemu-img convert -O raw /dev/vg_name/lv_name /path/to/disk.img
Disk Images
Find the Type and Size
If the disk is an image (qcow2/raw) or you have converted from LVM, you can easily reference the size and type using the following command:
qemu-img info /path/to/disk.img
Example output for a raw disk:
image: disk.img
file format: raw
virtual size: 10 GiB (10737418240 bytes)
disk size: 4 KiB
Example output for a qcow2 disk:
image: disk.img
file format: qcow2
virtual size: 10 GiB (10737418240 bytes)
disk size: 2.12 GiB
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
refcount bits: 16
corrupt: false
extended l2: false
The two important fields are file format (disk type) and virtual size (disk size).
Convert
VirtFusion defaults to qcow2 as it's storage type but also supports raw images. If the disk is not in the correct format, you can convert it easily.
The following commands will produce a copy of the original disk called new_disk.img.
Raw to Qcow2
qemu-img convert -f raw -O qcow2 /path/to/disk.img /path/to/new_disk.img
Qcow2 to Raw
qemu-img convert -f qcow2 -O raw /path/to/disk.img /path/to/new_disk.img
Networking
This part can get a little messy due to how some competing products create network configurations within a virtual server. If you would like VirtFusion to take full control of networking, you will need to make sure network configurations are correct.
Some OS images ship with a static network configuration baked into the image instead of relying on cloud-init. VirtFusion uses cloud-init to inject the correct network settings (IP addresses, gateway, and DNS) at boot, writing its generated configuration into a drop-in directory. If an imported image already contains a hard-coded network definition it will conflict with or override the cloud-init configuration, and the server may boot with the wrong network settings or no connectivity at all.
Check the image's network configuration before importing. A hard-coded interface definition is one of the most common reasons an imported server comes up without its assigned networking.
Interface Naming
Predictable Network Interface Device Names may have been disabled, i.e net.ifnames=0 and biosdevname=0 on the kernel command line in /etc/grub.conf. This can cause issues with cloud-init configuration where it expects predictable naming. This can mostly be resolved by setting an interface name in VirtFusion Server -> Network -> Interface Name and is explained in a later step.
Debian Interface File
Debian uses /etc/network/interfaces for network configuration. An imported image may define its interface directly in this file, for example:
auto eth0
iface eth0 inet static
address 192.0.2.10/24
gateway 192.0.2.1
Because VirtFusion writes the cloud-init generated configuration into /etc/network/interfaces.d/, the main /etc/network/interfaces file must be the stock cloud-init compatible version that only sources that directory:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
Remove any hard-coded physical interface stanzas so that only the loopback interface and the source line remain. Cloud-init then applies its generated configuration cleanly on boot.
Other Distributions
The same principle applies beyond Debian. Check for and remove hard-coded addresses in whichever network stack the image uses, for example:
- Netplan YAML in
/etc/netplan/*.yaml(Ubuntu) ifcfg-*scripts in/etc/sysconfig/network-scripts/(RHEL-based images such as Rocky Linux and AlmaLinux)- NetworkManager connection profiles in
/etc/NetworkManager/system-connections/
In each case, leave network configuration to cloud-init rather than pinning it in the image.
Install Cloud-Init & Guest Agent
It's wise to install cloud-init and the guest agent if possible. The following commands may not work on all disks and depend on the operating system installed on the disk.
Once you have completed this step, you should not boot the disk image until it has been imported into VirtFusion.
virt-customize -a /path/to/disk.img --install cloud-init,qemu-guest-agent
If you would prefer to install both these applications manually, you may do so using the stock distribution tools (apt, yum, dnf etc...).
Windows does not use the Cloud-Init package directly, and uses a solution called Cloudbase-Init which can be downloaded directly from here in MSI format. For guest agent installation, you can download the latest version here in MSI format.
VirtFusion Preparation
Create Server
To import a virtual server disk in to VirtFusion, you will need to create a new server with the same disk size as the disk you want to import. It's fine to specify 0 IPv4 as they can be added later (steps below) and is the recommended process.
Build Server
Install an operating system on the VM as close as you can to the operating system on the disk you plan to import. Pre-installing a similar operating system will make sure the internal configurations that VirtFusion makes will be a close match as possible.
Once it's built, shut the server down.
IP Configuration
If you have installed cloud-init in the previous steps, it's important you complete the IP Configuration process.
When building the server you may have specified how many IPs you wanted, and they will have been assigned. The important part here is to trigger cloud-init to only update the IP configuration.
To make cloud-init update the IP configuration you must make an IP change, even if the IPs are correct. Either add a new IP (Server -> Network -> Assigned IPv4) or remove an IP and re-add it. This will trigger VirtFusion to run an IP reconfiguration when the VM is started.
If your server needs a specific interface name, it can be configured in the network settings (Server -> Network -> Interface Name).
Import Disk
Disks are created in /home/vf-data/disk/ on a hypervisor if you are using the default location and the disk filename is in the format [UUID]_[DISK_ID].img. The UUID can be obtained from the admin area and the DISK_ID should be set to 1 for the primary disk.
Well use the UUID 043035a0-5887-4b05-888d-e83ff17f8174 in this example so the disk image path will be /home/vf-data/disk/043035a0-5887-4b05-888d-e83ff17f8174_1.img.
VirtFusion will always use the .img file extension for both qcow2 and raw images and can identify formats internally.
Copy the virtual server disk prepared earlier from the old hypervisor to the new VirtFusion hypervisor. You can do this via SCP, rsync or any other method suitable for transferring data to and from remote locations.
The examples below copy the disk into /home/vf-data/disk/ on the new hypervisor, ready to be renamed in the next step. Adjust the paths, IP address, and SSH user to match your environment.
Using scp, run from the old hypervisor:
scp /path/to/disk.img root@NEW_HYPERVISOR_IP:/home/vf-data/disk/
Using rsync, run from the old hypervisor. rsync is recommended for large disks because -P shows progress and lets an interrupted transfer resume where it left off:
rsync -avP /path/to/disk.img root@NEW_HYPERVISOR_IP:/home/vf-data/disk/
If the old hypervisor cannot reach the new one directly, run the transfer from the new hypervisor to pull the disk instead:
rsync -avP root@OLD_HYPERVISOR_IP:/path/to/disk.img /home/vf-data/disk/
For a large disk, run the transfer inside screen or tmux (or with nohup) so it continues if your SSH session drops. After the copy completes, you can confirm both files are identical by comparing their checksums with sha256sum /path/to/disk.img on each hypervisor.
Once the disk is on the new hypervisor, you will need to overwrite the disk created by VirtFusion:
mv /path/to/original/disk.img /home/vf-data/disk/043035a0-5887-4b05-888d-e83ff17f8174_1.img
Once copied, you should now be able to boot the server from within VirtFusion.
If all goes well and you have cloud-init installed, the networking should be configured automatically and the server will be online.