Hi Folks,
I’m about to migrate a VM from Xen, running on our own server, to K8 - probably running on Digital Ocean. Any hints on how to do this as easily as possible would be much appreciated.
Basic setup:
Looking for a simple way to convert the vm to an image that can run as a container on Digital Ocean, and for migrating the DRBD volume to a generic block storage service.
Any suggestions?
Thanks very much,
Miles Fidelman
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Hey!
That’s quite a legacy setup, nice one keeping it alive this long 🙂
I don’t think there is a direct path from a Xen VM like that to a container on DigitalOcean. Containers are a different model, so you usually don’t “convert” a full VM into a container image.
What people normally do is:
First migrate the VM as a VM
Then modernize it into a container later
For DigitalOcean, the simplest path would be:
Create a disk image from your Xen VM (raw or qcow2 if possible)
Spin up a Droplet and manually move the data over (rsync or similar)
Recreate the environment on the Droplet
For the DRBD volume, you can treat it like a normal disk and copy the data to a Droplet or to a Block Storage volume on DigitalOcean. There is no direct DRBD import, so it is more of a data migration than a lift and shift.
Once it is running on a Droplet, you can then slowly refactor it into containers and move to Kubernetes if that is your goal.
If you want less ops work, you could also look at DigitalOcean App Platform later instead of managing K8s directly.
I am not 100% sure if DO support can help with this kind of legacy migration, but it might still be worth asking here: https://do.co/support
Main idea is do it in steps, VM first, containers after, trying to jump directly will be very hard.
Good luck!
Heya, @milesrfidelman
Containerizing an old Xen DomU directly is usually more pain than it’s worth. You’d be ripping out the kernel, init system, hardware assumptions, etc. For a temporary “keep it limping along while we modernize” situation, I’d honestly skip the container path entirely and just move it to a Droplet as a VM. Way fewer surprises. You can always containerize the actual application later when you have time to do it properly.
If the goal really is K8s eventually, I’d treat it as two separate projects: 1) get the thing running on a Droplet first so it’s off the legacy hardware, 2) then properly containerize the application later when you understand what it actually needs.
Regards
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Full documentation for every DigitalOcean product.
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter.
New accounts only. By submitting your email you agree to our Privacy Policy
Scale up as you grow — whether you're running one virtual machine or ten thousand.
From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.