Converting Containers from Proxmox-VE back to plain old LXD/LXC


You can’t have failed to notice just how easy it’s become now to use a standard Ubuntu Linux install to manage and create Linux containers.

When I first started experimenting with these things, I was using Proxmox VE and it’s rather funky web frontend and plentiful custom scripts to manage my containers, and all was good.

The problem with Proxmox however, is… well It’s quite complicated.

Granted, if your using it in the same way you might use MS Hyper-V to consolidate your physical hardware all into a virtual space, then great, you learn what you need to know, host your VM’s and jobs a goodun.

But what of your doing things like dev-ops, where your spinning up and tearing down containers here there and everywhere.

Proxmox has an API but it’s horribly contorted and not at all simple to use or even understand for that matter, so then you have to install k8s, chef, puppet, ansible or some other mind blowing toolset that helps to to automate things, and the learning curve that comes with that.

Then we have docker, and it’s not so simple way of containerisation.

Recently with the changes in LXD/LXC and how easy it’s now become to do regular containers on a regular Linux system with no special setup, I decided to ditch my Proxmox VE set up, and just go for a simple bare bones, no frills Ubuntu Server with LXD installed approach.

The problem was, getting my containers off Proxmox and back into standard LXC formats.

Proxmox uses custom EVERYTHING

In case you didn’t already know, Proxmox has a custom interface for everything, with commands like “pct”, granted some of it is because the underlying software is still on older versions, but a lot of it is simply so they can stamp their own authority on how you do things and exert some level of control.

This as you can imagine, makes it a bit of a pain to revert back to a non Proxmox system.

This was the problem I had. I had a number of containers running on my proxmox server that I wanted to keep running, without having to go to the trouble of re-installing our re-building anything. During my many searches, I found masses and masses of information and articles on how to install and move onto Proxmox, but next to nothing to come back the other way and the hostility in some of the forums when asking questions about moving OFF the platform was so much so that I just wasn’t prepared to get involved in any discussions on the topic.

As you may have guessed by now, I eventually worked out how to do it, and to be fair it’s not all that hard once you get down to it.

Exporting the containers

The first thing you need, is your container in a format that LXD can use. You might be tempted to read the PCT manual for an export command, but the simplest way is to use the virtual machine backup tool “vzdump”

You create a tar.gz of your container simply by using the following command:

vzdump 115 -compress gzip -dumpdir /tmp

Proxmox CLI showing VZDump command.

As you can see from the command line, the container is a numerical ID, so in order to find the number of the container you want to work with, you first need to list your containers. You can do this from the Proxmox web interface, or from the command line by typing:

pct list

and pressing return.

pct list shows your container list and ID’s

In my example above I’ve chosen to force the backup file to be put in the /tmp folder, if you don’t specify the path then by default you end up with it buried 10 levels down, some where beginning with /var/lib/dump/lxd/backups/dumps/…. or some similar craziness.

either way, once you finally get a backup of your container, you’ll have a file named something similar to:

vzdump-lxc-115-2021_11_16-18_59_21.tar.gz

Which as you can see encodes the container ID and the date/time it was dumped.

Once you have the tar.gz of your container file system, you then need a metadata file that describes the container, ready for use by LXD.

By rights, this should actually be added directly to the file system archive, but unpacking it, adding it then re-packing it all in the right format, order and folder structure is a bit of a pain to say the least.

Fortunately, LXD can take the files separately, so all we need to do is create a yaml file called “metadata.yaml” then tar gz it into it’s own file, and surprisingly this file only has to have 2 items minimum in it, an architecture tag, and a date_created tag.

Using the PCT config and date commands, means that creating the yaml file is as easy as using the following 2 shell commands:

echo architecture: 'pct config $1 | grep arch: | awk '{print $2}' ' > metadata.yaml

echo creation_date: 'date +%s' >> metadata.yaml

Take note that those outer ‘ symbols are “backticks” as the following image shows:

Proxmox CLI showing the backtick enabled commands to write the metadata file.

If you display the config for the container you just backed up using vzdump, you’ll see the first line is the architecture of your container, the second can be any random 32 bit integer to be fair, but I generated it using the data command as shown in the image.

However you do it, the file you will end up with should look something like the following:

Metta data file consists of only 2 lines.

the architecture and the create date are all you need.

Once your yaml file is complete, add it to it’s own tar gz file using the following command:

tar -czvf metadata.tar.gz metadata.yaml

These 2 tar.gz files are all you need, so copy them in which ever way makes sense to you, to the machine with only LXD/LXC on, for my tests I just used rsync.

Restoring the machine on your LXD node is a 2 step process, first you import your machine as an image, then you create a new machine based on the image.

To import the two files into an image, use the following:

lxc image import metadata.tar.gz vzdump-lxc-115-2020_11_11-17_31_29.tar.gz

Remembering to change the filenames as needed for your files.

The first file name is the metadata archive, the second is the backup files created by vzdump.

Importing the image using LXC

Ignore the error in the above image, it’s only because I’ve already imported my container image and not cleaned up yet.

Once you’ve imported the image, if you then perform an:

lxc image list

command, you should see that a new image with a fingerprint has been deployed.

LXC list of installed template images

Once you have the image, you can then use this template to create a new instance of your original proxmox container, using the fingerprint listed in the images table list:

lxc launch 9b20fa348108 newcontainername

If all has gone ok, then issuing:

lxc list

should show something like the following:

lxc list shows our new container.

At this point you can use:

lxc image delete 9b20fa348108

to delete the temporary image and free up disk space, followed by removing the two tar.gz files you created in the process.

Configuring bridges, network addresses and other similar things is a little beyond the scope of this article, that’s a topic for another post.

Shawty

2 thoughts on “Converting Containers from Proxmox-VE back to plain old LXD/LXC

  1. Thanks; Useful information. Did you try this with KVM/QEMU images? We did a similar thing. depoloyed on Proxmox; then moved to LXD

    1. Yes absolutely. this was my primary motivation for working out how to do this.

      I’d previously installed a proxmox cluster, which A) didn’t allow me to do some of the things I wanted to do with my .NET apps and B) was actually taking more to admin and keep up to date than just LXC/LXD on it’s own.

      Eventually I gave up on proxmox and the headaches it was causing.

      Not only that, but the proxmox team where getting more and more aggressive with the push to a paid subscription, which I was getting fed up of too.

      I have 2 VM environments, MS-HyperV (Which I pay for) and my LXD/LXC deployment, which is essentially my experimenting platform, and I wasn’t about to jump to a paid proxmox install when I was paying for industrial strength HV.

      So I decided to ditch Proxmox, but I had a number of images that I needed to port before I could abandon proxmox, the blog post was the result of my research into doing it properly and getting it working.

Leave a comment