Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Current upstream has all the hookups for creating LXC guests and specifying <filesystem> devices. Main thing lacking at the moment is a tool to actually populate an OS directory tree. I've got something half working but it has various hacks in it that should probably be investigated before actually recommending it to customers.

(In reply to comment #3)

Hello Cole, would you consider sharing your information on populating a RHEL (say 6.1) OS directory tree?  Understand it would be a work in progress, but it would be nice to get a feel for what will presumably eventually be the recommended way of doing this.

So far, to make an LXC environment in 6.1 (barely) useable:
(1) I am using libvirt 0.91 because it appears to resolve many bugs opened against LXC while we wait for the relevant fixes to be backported to the version shipped with RHEL.  RPMs rebuilt from http://libvirt.org/sources/libvirt-0.9.1-1.fc14.src.rpm.  In my case, using stock RHEL 6.1 libvirt triggers bug https://bugzilla.redhat.com/show_bug.cgi?id=698071. 

(2) The filesystem image is a copy of a freshly kickstarted VM.  Works fine with a libvirt <init> of /bin/sh.  Unfortunately this doesn't start services, and isn't very resilient as "exit" will stop the container (terminates the shell).

I'm experimenting with an <init> of /sbin/init, but:
- udev must not start.  The udev-post service can be stopped in a standard way. /sbin/start_udev has to be commented out of /etc/rc.d/rc.sysinit which isn't clean, a switch under /etc/sysconfig would be better.
- ensuring that the container's console is segregated from the main instance needs some work.  I'm still looking at what's going on here with libvirt 0.9.1

Fixed in python-virtinst-0.600.0-1.el6

Martin, here's the steps I used to get a full FS container up and running on F15. This is basically a list of hacks and I'm guessing is unsupportable, so take it with a grain of salt. This was on Fedora 14

# Populate dir
mkdir -p testdir/var/lib/rpm
mkdir -p testdir/var/log
yumdownloader --destdir testdir fedora-release
rpm --root testdir --initdb
rpm --root testdir -ivh testdir/fedora-release*
yum --installroot=testdir -y groupinstall Base

# Set a root passwd
#chroot testdir
#passwd

# Add pts/0 to /etc/securetty
# Makes root login act same as non root login, prompting:
# Would you like to enter a security context (and then bailing)

# Edit /etc/pam.d/login, comment out selinux lines
# root prompt takes password and goes right back to login:

# Edit /etc/pam.d/login, comment out loginuid line
# root prompt works!

# Edit /etc/rc.sysinit, disable /sbin/start_udev
# Quieter boot up

# Created /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=myinit

# Create /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes

# chkconfig NetworkManager off
# chkconfig network on
# Gets startup networking

# Add a basic /etc/fstab with
# tmpfs  /dev/shm   tmpfs  defaults  0 0
# Made startup a bit happier, no noticeable effect

according by comment 12,
verify on python-virtinst-0.600.0-3.el6
step:
1: run command line :
#cd /tmp
#febootstrap fedora-13 rootfs.fedora
2: after install complete, disable selinux on host and fedora-13
#chroot /tmp/rootfs.fedora
(by comment 12 settings)
3: run command line:

#virt-install --connect lxc:/// -n demo -r 1024 --filesystem
/tmp/rootfs.fedora,/ --debug

# virsh -c lxc:/// list --all
Id Name                 State
----------------------------------
10331 demo                 running

use virt-manager to login the vm successful.
move to verify.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
New Feature:
virt-install can now be used to create linux container guests. This includes application containers and full OS containers. However, no tool for creating an OS directory tree is provided, users must manually build one.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1643.html