In my tutorial “Replace Proxmox with LXD” I demonstrated how to migrate a Proxmox LXC container to a LXD container. In this presentation we will learn how to migrate a Proxmox Virtual Machine to a LXD Virtual Machine.
NOTE: You cannot migrate between dissimilar architectures. For example, if your source VM is on x86-64, your target VM cannot use the ARM architecture.
In my first example, we moved a Nextcloud VM from Proxmox to a LXD VM. This Ubuntu Server instance is running Ubuntu 22.04 Server and it has a FAT32 EFI Boot drive and a GUID Partition table on a drive hosting the root partition and formatted to ext-4.
NOTE: You should make sure that your Proxmox VM is using the VirtIO drivers. That should be a given because Proxmox VM’s use QEMU.
Log into an ssh session on your Proxmox server (your address will vary):
Move to the “tmp” partition which we will use as our scratch space:
List the virtual machine disk containers on the Proxmox host:
Identify the disk image(s) that you need to convert. In my case, I have one for the EFI disk and one for the root disk. I am converting these to .qcow2 images:
qemu-img convert -O qcow2 /dev/pve/vm-101-disk-0 /tmp/nextcloudvm0.qcow2 qemu-img convert -O qcow2 /dev/pve/vm-101-disk-1 /tmp/nextcloudvm1.qcow2
Next, I use secure copy to copy these images to a scratch folder on my LXD server:
scp /tmp/nextcloudvm0.qcow2 email@example.com:/home/scott/Desktop/migrate scp /tmp/nextcloudvm1.qcow2 firstname.lastname@example.org:/home/scott/Desktop/migrate
Now you can delete these files on the Proxmox tmp folder because they are no longer needed:
Now you need to “ssh” to your LXD server and move to the folder where you copied the .qcow2 images.
We need to create a metadata file for the VM image creation:
Put data like the following in the file (yours will differ):
architecture: x86_64 creation_date: 1324284563 properties: description: NextCloud Server os: Ubuntu release: 22.04
Do a CTRL O and enter to save the file and a CTRL X to exit the editor.
We need to “tar” the metadata file before we can use it.
tar -czvf metadata.tar.gz metadata.yaml
Now we can import the files to the LXD server to create the virtual machine image. Note that the alias name that you choose cannot have spaces in the name:
lxc image import metadata.tar.gz nextcloudvm0.qcow2 nextcloudvm1.qcow2 --alias NextCloud-Image
You can list the image we just created:
lxc image list
We can now create a Virtual Machine in LXD from the image:
lxc launch NextCloud-Image NextCloud -c boot.autostart=true
Since the Ethernet device name on your Proxmox NextCloud virtual machine will not be the same as the Ethernet device name on your LXD Virtual Machine, we need to change the name.
Connect to the newly created container:
lxc shell NextCloud
Find out the Ethernet device name on the new container:
Move to the Netplan folder on the LXD VM.
Edit the netplan file and change the name (for example, my Proxmox ethernet device was “ens18” and my LXD VM device name is enp5s0):
Save the file with CTRL O and Enter and then CTRL X to exit the editor.
Apply the new network settings:
Exit the LXD VM container back to your LXD host:
Watch my “LXD Step by Step” tutorial to understand how to create a “bridgeprofile” to offer your LXD VM on your main LAN.
To offer your LXD VM on the main LAN assuming you followed the tutorial just mentioned:
lxc profile assign NextCloud default,bridgeprofile
In the video, NextCloud is kind of a special case application and it did not like having its IP address changed.
To rectify this for NextCloud I connected back to the container shell:
lxc shell NextCloud
I searched for the config.php file:
find / -type f -name config.php
In my case, my NextCloud was installed via a SNAP and so I edited the file:
I searched for “trusted” using a CTRL W in nano and I changed the IP address to the address of the LXD VM. Then I saved the file with CTRL O and enter and a CTRL X to exit the nano editor.
I then rebooted the NextCloud LXD VM:
The NextCloud image in the LXD VM is now running without issues.
The second Virtual Machine migration that I covered on the video was from a Proxmox VM running Ubuntu desktop. This was different from the NextCloud migration because the Ubuntu desktop had a single disk image configured with a FAT partition table and used the older master boot record (MBR) booting method. The Ubuntu Desktop root disk was formatted ext-4 as is normal.
On FAT/MBR Booting instances of VM’s you must install lxd-agent-9p and lxd-agent.
On Proxmox, log into your Desktop Virtual machine and install openssh for convenience.
sudo apt install openssh-server
Connect to your Proxmox VM via ssh (your username/address will differ):
We need to install lxd-agent-9p and lxd-agent on the Proxmox Virtual Machine that we are moving. Note that in the case of the NextCloud server this step was not needed because EFI booting VM’s seemed to have these components already installed.
Create the 9p agent:
cat > /lib/systemd/system/lxd-agent-9p.service << EOF [Unit] Description=LXD - agent - 9p mount Documentation=https://linuxcontainers.org/lxd ConditionPathExists=/dev/virtio-ports/org.linuxcontainers.lxd After=local-fs.target DefaultDependencies=no [Service] Type=oneshot RemainAfterExit=yes ExecStartPre=-/sbin/modprobe 9pnet_virtio ExecStartPre=/bin/mkdir -p /run/lxd_config/9p ExecStartPre=/bin/chmod 0700 /run/lxd_config/ ExecStart=/bin/mount -t 9p config /run/lxd_config/9p -o access=0,trans=virtio [Install] WantedBy=multi-user.target EOF
Now create the lxd agent:
cat > /lib/systemd/system/lxd-agent.service << EOF [Unit] Description=LXD - agent Documentation=https://linuxcontainers.org/lxd ConditionPathExists=/dev/virtio-ports/org.linuxcontainers.lxd Requires=lxd-agent-9p.service After=lxd-agent-9p.service Before=cloud-init.target cloud-init.service cloud-init-local.service DefaultDependencies=no [Service] Type=simple WorkingDirectory=/run/lxd_config/9p ExecStart=/run/lxd_config/9p/lxd-agent Restart=on-failure RestartSec=5s StartLimitInterval=60 StartLimitBurst=10 [Install] WantedBy=multi-user.target EOF
Enable both of these services so that they will run at startup of the VM:
systemctl enable lxd-agent-9p.service systemctl enable lxd-agent.service
Now exit your Proxmox VM ssh session and ssh back into the Proxmox ssh session and move back to the “/tmp” folder on the Proxmox server.
Look for the disk images:
Convert the image to a qcow2 format:
qemu-img convert -O qcow2 /dev/pve/vm-102-disk-0 /tmp/ubuntudesktop.qcow2
Move the image to our LXD server:
scp /tmp/ubuntudesktop.qcow2 email@example.com:/home/scott/Desktop/migrate
You can delete the image on the Proxmox server:
Exit the Proxmox server and sign into the LXD server (your addres will vary):
exit ssh 172.16.1.225 cd /home/scott/Desktop/migrate
Create the metadata file for this container. Note that I simply edited mine:
I inserted the following data:
architecture: x86_64 creation_date: 1324284563 properties: description: Ubuntu Desktop os: Ubuntu release: 22.04
I delete the old metadata tar file:
TAR the new metadata.yaml:
tar -czvf metadata.tar.gz metadata.yaml
Import the new image for the Ubuntu Desktop VM:
lxc image import metadata.tar.gz ubuntudesktop.qcow2 --alias Ubuntu-Desktop
List your images on the LXD server:
lxc image list
Create a LXD VM from the image:
lxc launch Ubuntu-Desktop UbuntuDesktop -c boot.autostart=true
Change the new LXD VM to have an address on your LAN:
lxc profile assign UbuntuDesktop default,bridgeprofile
Connect to the shell of the new LXD VM:
lxc shell UbuntuDesktop
Optional: You can install and run a script to configure an RDP server on your desktop VM. To do this, be sure you are logged into your user account and that your user account has sudo privilege. The script will not work from the root account:
su - scott
Download and run the RDP script as shown in the video:
wget https://c-nergy.be/downloads/xRDP/xrdp-installer-1.4.zip unzip xrdp-installer-1.4.zip bash xrdp-installer-1.4.sh
The Ubuntu Desktop Virtual Machine instance from Proxmox is now running as a LXD VM on your LXD server and you can RDP into it with any RDP client.
Note: You can delete the LXD Images that we created once you launch your LXD VM. The only reason to keep the images is if you want to create additional containers from the image.