[Lxc-users] Converting an LXC container into a bootable OS?

[Ivan Fetch]

Hi,

Our first try at converting an LXC to a VMware virtual machine went well.

IN this case, we used our backup infrastructure to copy the lxc contents into a virtual machine disk seeded with the same distribution and version of Linux, but there are other (likely easier) ways to copy the LXC data directly from the LXC host (rsync, or tar).

This process probably could be made simpler, by mounting the VMware VMD and copying the LXC contents directly into it.

Since the LXC has no /boot, does not use it's own kernel, ETc, the quickest path to getting an LXC into a VM seemed to be the below steps. IF anyone has reasons against starting with a base install of Linux, then copying the LXC contents into that install, I'd be interested to hear from you.

1. Use a "helper" virtual machine, with our backup software installed in the guest OS. It doesn't really matter what flavor of Linux this VM runs, as long as the UIDs of ext2 partitions, physical volumes, and other LVM components do not conflict with the disk(s) you'll be attaching to this VM in step 3.

2. Create a second VM, where the LXC will be copied. Install the same distribution and version of Linux, that is running in the LXC. I did not bother to update packages in this VM, and I kept the install as minimal as possible, so there is no chance of having something which is a later version in the new VM, than in the contents of the LXC.
 
3. SHutdown both VMs, and attach the LXC VM's disk to the helper VM. YOu can do this as long as you do not try to power on the second (LXC) VM while the first (helper) VM is powered on. IF both of these VMs came from the same VM template, you will probably have two disks sharing the same set of UIDs - you can either boot from a CD and change UIDs for physical volumes, ext2 partitions, logical volumes, Etc, or you can clone the second VM from another template, or do a quick re-install. Make sure this VM is based on the same OS distribution and version as is running in the LXC.

4. Boot the helper VM, and mount the disk of the LXC VM (where you plan to copy the LXC contents. Use lvdisplay, to find the logical volumes located on the disk(s) for the LXC VM. DOn't forget to mount the /boot and the root filesystems. E.G.
mkdir -p /lxc
mount /dev/mapper/VolGroupOfLXCDisk/root /lxc
mount /dev/sdb1 /lxc/boot

5. Copy the lxc contents into the mountpoint of the second disk (/lxc).

6. Unmount the extra disks, shutdown the helper VM, and boot the second (LXC) VM. Once things look good, detach the second VM's disk from the helper VM.


- Ivan

On Oct 11, 2011, at 8:10 PM, Iliyan ilf Stoyanov wrote:

> Hi Ivan,
> 
> On Tue, 2011-10-11 at 18:32 -0600, Ivan Fetch wrote:
>> Hello,
>> 
>> Along with some other troubleshooting we are doing (separate thread), we are investigating turning some LXC containers into virtual machines. Does anyone have experience, or perhaps some write-ups, on going in the other direction? E.G> start with a base Ubuntu 10.04 installation, copy the LXC contianer's filesystem into that installation, then adjust fstab, rebuilt initrd image, Etc?
> 
> It shouldn't be that hard doing that. All you need to take into account
> is the 'hardware' inside your virtual machine. I always assume people
> use KVM/Qemu so basically you should probably take into account the
> appropriate vda/hda drivers, the virtio drivers for the network
> interfaces, etc. 
> 
> Once upon a time I used to install server by booting from NFS and
> effectively copying the live NFS FS to the local harddrives, chrooting
> there and doing kudzu and then mkinitrd by including specific kernel
> modules for the hardware on the machine, raid, etc, so I can boot it,
> but that was on RHEL4. I would have to say nowadays I do that, but the
> tools are very different between distros. RHEL and Fedora use dracut for
> generating the initrd and partially probing hardware. I'm not really
> familiar with the fine details of ubuntu, but I think mkinitrd (or the
> appropriate analog) still allows you to include modules by hand. Then
> you should setup your fstab file and essentially start the machine.
> 
> As for the exact creation of the image (I assume you'll be using images)
> qemu-img would help you create the appropriate format, and eventully
> mount it as a loop device. If you don't change hardware platforms (i.e.
> x86_64 on i386 host, or PowerPC on x86(_64) instruction set host) you
> mount the img. Copy the LXC container FS to it, mount
> --bind /{proc,sys,dev} to the root of the loop device, chroot there and
> then mkinitrd with proper modules from the appropriate kernel version.
> Then you setup the fstab, put a boot loader on the image and edit it's
> config and attempt to boot from that qemu image. It is almost like
> copying the FS on real server, just with different kernel modules.
> 
> This is just a quick and dirty howto that assumes you are using
> KVM/Qemu, but I think it will not be that much different for other
> hypervisors.
> 
> Hope I was some help. Unfortunately I don't have the time lately to sit
> down and write a detailed howto, because actually it would make a good
> algorithm and I can write a small script for converting LXC machines to
> KVM, and vice versa  as I'm almost certain I'll need such a thing at
> some point.
> 
> cheers,
> -- ilf
>> 
>> Thanks,
>> 
>> Ivan.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> .
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2d-oct
>> _______________________________________________
>> Lxc-users mailing list
>> Lxc-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/lxc-users
> 
> 























.