Diff for "Running/LXC"

Not logged in - Log In / Register

Differences between revisions 24 and 25
Revision 24 as of 2011-06-22 06:56:43
Size: 4297
Editor: lifeless
Comment: bind mounts
Revision 25 as of 2011-06-22 08:45:02
Size: 3486
Editor: lifeless
Comment: and we're done
Deletions are marked like this. Additions are marked like this.
Line 67: Line 67:
 1. Grab the ip address (handed out via libvirt's dhcp server) - you may wish to ssh in rather than using the console (seems to have better termcap experience).
{{{
ip addr show dev eth0 | grep 'inet'
}}}
Line 69: Line 74:
 1. Grab your user id and username so you can setup a bind mount outside the container:  1. (Outside the container) grab your user id and username so you can setup a bind mount outside the container:
Line 89: Line 94:
 1. Start it up again - headless now, we have the ip address from before.
{{{
sudo lxc-start -n lucid-test-lp -d
}}}
Line 90: Line 99:
 1. below this is not yet updated from the vm instructions  1. ssh <vm IP address> to connect to the VM. Your ssh key is already present because of the bind mount to your home dir.
Line 92: Line 101:
 1. After its installed, connect to the image and install {{{acpid}}} and {{{openssh-server}}}  1. You can now follow the [[Getting|getting-started]] on LP instructions. Be warned that changes in ~ will affect you outside the container.
Line 94: Line 103:
 1. Use ssh-copy-id to copy your public key into the VM.

 1. ssh -A <vm IP address> to connect to the VM.

 1. {{{bzr whoami "Your Name <your.email@example.com>"}}} to set your bzr identity in the VM.

 1. You can now follow the [[Getting|getting-started]] on LP instructions.
 1. You probably want to follow [[Running/RemoteAccess]] has a discussion for how you can configure things so your non-container browser can access web pages from within the container.
Line 104: Line 107:
See also this email thread about [[https://lists.launchpad.net/launchpad-dev/msg03456.html|running Launchpad in a virtual machine]], and this [[https://lists.launchpad.net/launchpad-dev/msg03454.html|discussion of the differences]] between running in a [[Running/Schroot|chroot]] environment and running a VM. [[Running/RemoteAccess]] has a discussion for how you can configure the VM to allow the host machine to access the web pages, etc.
Line 108: Line 110:
You can skip some manual steps of installing from an ISO using a command like this:

{{{
sudo ubuntu-vm-builder kvm lucid --domain vm --dest ~/vm/lp-dev \
 --hostname lp-dev \
 --mem 2048 --cpus 2 \
 --components main,universe,multiverse,restricted \
 --mirror http://10.113.3.35:3142/mirror.internode.on.net/pub/ubuntu/ubuntu \
 --libvirt qemu:///system \
 --debug -v \
 --ssh-user-key ~/.ssh/id_rsa.pub --ssh-key ~/.ssh/id_rsa.pub \
 --rootsize 24000 \
 --user $USER
}}}

After installation completes, it should show up in your virt-manager menu.

= In LXC =

It seems like it would be nice to run Launchpad in [[http://lxc.teegra.net/|LXC containers]]: they should be more efficient than a VM (especially with regard to memory and disk) but more isolated than a chroot. More testing or documentation is needed.
You can also run in a [[Running/Schroot|chroot]] environment or a [[Runnining/VirtualMachine|VM]].

This page explains how to set up and run Launchpad (for development) inside a LXC.

Why?

Launchpad development setup makes significant changes to your machine; its nice to be unaffected by those except when you are actually doing such development.

Also, launchpad has some limitations on concurrent testing per-machine and so forth - multiple container's can be used to work around this.

Make a LXC

  1. Install lxc

sudo apt-get install lxc
  1. Work around 800456

sudo apt-get install cgroup-bin
  1. Work around 784093

sudo dd of=/etc/cgconfig.conf << EOF
mount {
 cpu = /sys/fs//cgroup/cpu;
 cpuacct = /sys/fs/cgroup/cpu;
 devices = /sys/fs/cgroup/cpu;
 memory = /sys/fs/cgroup/cpu;
}
EOF
sudo service cgconfig restart
  1. Work around 798476 (optional if you run i386 or have a -tonne- of memory and don't care about 64-bit footprint.

    • Grab the patch from the bug and apply it to /usr/lib/lxc/templates/lxc-lucid. If you're running i386 already or want a 64-bit lxc then do not pass arch= on the lxc-create command line.
  2. Create a config for your containers

sudo dd of=/etc/lxc/local.conf << EOF
lxc.network.type=veth
lxc.network.link=virbr0
lxc.network.flags=up
EOF
  1. Create a container

sudo arch=i386 lxc-create -n lucid-test-lp -t lucid -f /etc/lxc/local.conf
  • If you want to use a proxy

sudo arch=i386 http_proxy=http://host:port/ lxc-create -n lucid-test-lp -t lucid -f /etc/lxc/local.conf
  • And if you want to set a custom mirror, similar to http_proxy, but set MIRROR= instead.
  1. Start it

sudo lxc-start -n lucid-test-lp
  • Ignore the warning about openssh crashing - it restarts on a later event. The initial credentials are root:root.
  1. Grab the ip address (handed out via libvirt's dhcp server) - you may wish to ssh in rather than using the console (seems to have better termcap experience).

ip addr show dev eth0 | grep 'inet'
  1. The new container won't have your proxy / mirror settings preserved. Customise it at this point before going further if you care about this.
  2. (Outside the container) grab your user id and username so you can setup a bind mount outside the container:

id -u
id -nu
  1. Inside the container add the user:

adduser --uid $id $username
  1. To stop it now run 'poweroff -n'.
  2. Setup a bind mount so you can access your home dir (and thus your LP source code) from within the lxc container:
    • edit /var/lib/lxc/lucid-test-lp/fstab
    • Add a line:

/home/$username /var/lib/lxc/lucid-test-lp/rootfs/home/$username none bind 0 0
  1. Start it up again - headless now, we have the ip address from before.

sudo lxc-start -n lucid-test-lp -d
  1. ssh <vm IP address> to connect to the VM. Your ssh key is already present because of the bind mount to your home dir.

  2. You can now follow the getting-started on LP instructions. Be warned that changes in ~ will affect you outside the container.

  3. You probably want to follow Running/RemoteAccess has a discussion for how you can configure things so your non-container browser can access web pages from within the container.

References

Alternatively

You can also run in a chroot environment or a VM.