lxc.container.conf(5) lxc.container.conf(5)

lxc.container.conf - پرونده پیکربندی کانتینر LXC

LXC یک زمان‌اجرای سطح‌پایین، شناخته‌شده و کاملاً آزموده‌شده برای کانتینرهای لینوکس است. توسعه آن از سال 2008 به صورت فعال در جریان است و کارایی خود را در محیط‌های عملیاتی حساس در سراسر جهان به اثبات رسانده است. برخی از مشارکت‌کنندگان اصلی آن، همان افرادی هستند که به پیاده‌سازی ویژگی‌های گوناگون و سرشناس کانتینرسازی در داخل هسته لینوکس کمک کرده‌اند.

تمرکز اصلی LXC بر کانتینرهای سیستمی است؛ یعنی کانتینرهایی که محیطی تا جای ممکن نزدیک به یک ماشین مجازی (VM) فراهم می‌کنند، بدون آن‌که سربار ناشی از اجرای یک هسته جداگانه و شبیه‌سازی تمام سخت‌افزارها را به همراه داشته باشند.

این امر از طریق ترکیب قابلیت‌های امنیتی هسته مانند فضاهای نام (namespaces)، کنترل دسترسی اجباری (mandatory access control) و گروه‌های کنترل (control groups) محقق می‌شود.

سامانه LXC از کانتینرهای غیرممتاز (unprivileged) پشتیبانی می‌کند. کانتینرهای غیرممتاز، کانتینرهایی هستند که بدون هیچ‌گونه امتیاز ویژه‌ای اجرا می‌شوند. این قابلیت نیازمند پشتیبانی از فضاهای نام کاربر (user namespaces) در هسته‌ای است که کانتینر روی آن اجرا می‌شود. پس از ادغام فضاهای نام کاربر در شاخه اصلی هسته لینوکس، LXC نخستین زمان‌اجرایی بود که از کانتینرهای غیرممتاز پشتیبانی کرد.

در اصل، فضاهای نام کاربر مجموعه‌های مشخصی از UIDها و GIDها را جداسازی می‌کنند. این کار با ایجاد یک نگاشت (mapping) بین محدوده‌ای از UIDها و GIDها روی میزبان و محدوده‌ای متفاوت (غیرممتاز) از UIDها و GIDها در کانتینر انجام می‌شود. هسته این نگاشت را به‌گونه‌ای ترجمه می‌کند که درون کانتینر تمام UIDها و GIDها همان‌طور که از میزبان انتظار دارید دیده شوند، در حالی که روی سیستم میزبان این شناسه‌ها در واقع غیرممتاز هستند. برای نمونه، فرآیندی که با UID و GID برابر 0 در کانتینر اجرا می‌شود ممکن است روی میزبان با UID و GID برابر 100000 دیده شود. جزئیات پیاده‌سازی و نحوه عملکرد را می‌توان از صفحه راهنمای مربوط به user_namespaces به دست آورد. نگاشت‌های UID و GID را می‌توان با کلید lxc.idmap تعریف کرد.

کانتینرهای لینوکس با یک پرونده پیکربندی ساده تعریف می‌شوند. هر گزینه در پرونده پیکربندی به صورت key = value در یک خط قرار می‌گیرد. نویسه «#» نشان‌دهنده خط توضیحات (کامنت) است. گزینه‌های فهرستی، مانند گزینه‌های قابلیت‌ها (capabilities) و cgroups، می‌توانند بدون مقدار استفاده شوند تا مقادیر پیش‌تر تعریف‌شده برای آن گزینه پاک شوند.

کلیدهای پیکربندی فضاهای نام LXC از نقطه‌های تکی استفاده می‌کنند. این بدان معناست که کلیدهای پیکربندی پیچیده مانند lxc.net.0 زیرکلیدهای گوناگونی مانند lxc.net.0.type، lxc.net.0.link، lxc.net.0.ipv6.address و موارد دیگر را برای پیکربندی بسیار دقیق‌تر ارائه می‌دهند.

برای تسهیل مدیریت چندین کانتینر مرتبط، این امکان وجود دارد که یک پروندهٔ پیکربندی کانتینر باعث بارگذاری پرونده‌ای دیگر شود. برای نمونه، پیکربندی شبکه می‌تواند در یک پروندهٔ مشترک تعریف شود که توسط چندین کانتینر گنجانده می‌شود. سپس، در صورت انتقال کانتینرها به میزبانی دیگر، تنها نیاز به به‌روزرسانی یک پرونده خواهد بود.

پرونده‌ای که باید گنجانده شود را مشخص می‌کند. پروندهٔ گنجانده‌شده باید با همان قالب پروندهٔ پیکربندی معتبر lxc باشد.

امکان تعیین معماری را برای کانتینر فراهم می‌کند. برای نمونه، تنظیم معماری ۳۲ بیتی برای کانتینری که برنامه‌های دودویی ۳۲ بیتی را بر روی یک میزبان ۶۴ بیتی اجرا می‌کند. این کار اسکریپت‌های کانتینر را که برای انجام اموری مانند بارگیری بسته‌ها به معماری وابسته هستند، اصلاح می‌کند.

معماری کانتینر را مشخص می‌کند.

برخی گزینه‌های معتبر عبارتند از: x86, i686, x86_64, amd64

بخش utsname نام میزبان تعیین‌شده برای کانتینر را تعریف می‌کند. این بدان معناست که کانتینر می‌تواند بدون تغییر نام میزبان سیستم، نام میزبان اختصاصی خود را تنظیم کند. این کار نام میزبان را برای کانتینر خصوصی می‌سازد.

نام میزبان را برای کانتینر مشخص می‌کند.

امکان مشخص کردن نام یا شماره سیگنال ارسالی به فرایند init کانتینر را برای خاموش کردن پاکیزه کانتینر فراهم می‌کند. سیستم‌های init مختلف ممکن است از سیگنال‌های متفاوتی برای اجرای توالی خاموش‌سازی پاکیزه استفاده کنند. این گزینه اجازه می‌دهد سیگنال به شیوه kill(1) مشخص شود، مانند SIGPWR، SIGRTMIN+14، SIGRTMAX-10 یا یک شماره ساده. سیگنال پیش‌فرض SIGPWR است.

سیگنال مورد استفاده برای متوقف ساختن کانتینر را مشخص می‌کند

امکان مشخص کردن نام یا شماره سیگنال برای راه‌اندازی مجدد کانتینر را فراهم می‌کند. این گزینه اجازه می‌دهد سیگنال به شیوه kill(1) مشخص شود، مانند SIGTERM، SIGRTMIN+14، SIGRTMAX-10 یا یک شماره ساده. سیگنال پیش‌فرض SIGINT است.

سیگنال مورد استفاده برای راه‌اندازی مجدد کانتینر را مشخص می‌کند

امکان مشخص کردن نام یا شماره سیگنال برای خاموش کردن اجباری کانتینر را فراهم می‌کند. این گزینه اجازه می‌دهد سیگنال به شیوه kill(1) مشخص شود، مانند SIGKILL، SIGRTMIN+14، SIGRTMAX-10 یا یک شماره ساده. سیگنال پیش‌فرض SIGKILL است.

سیگنال مورد استفاده برای متوقف کردن کانتینر را مشخص می‌کند

فرمانی که باید به عنوان سیستم init برای کانتینرها استفاده شود را تنظیم می‌کند.

مسیر مطلق از rootfs کانتینر به باینری برای اجرا به صورت پیش‌فرض. این گزینه بیشتر برای lxc-execute کاربرد دارد.
مسیر مطلق از rootfs کانتینر به باینری برای استفاده به عنوان init. این گزینه بیشتر برای lxc-start کاربرد دارد. پیش‌فرض /sbin/init است.

مسیر مطلق درون کانتینر را به عنوان دایرکتوری کاری برای کانتینرها تنظیم می‌کند. LXC پیش از اجرای init به این دایرکتوری منتقل خواهد شد.

مسیر مطلق درون کانتینر جهت استفاده به عنوان دایرکتوری کاری.

شناسه UID/GID را برای استفاده توسط سیستم init و فرمان‌های پس از آن تنظیم می‌کند. توجه داشته باشید که استفاده از UID غیر ریشه (non-root) هنگام بوت کردن یک کانتینر سیستمی به دلیل عدم وجود دسترسی‌های لازم احتمالاً کار نخواهد کرد. تنظیم UID/GID بیشتر هنگام اجرای کانتینرهای برنامه‌ای کاربرد دارد. پیش‌فرض: UID(0), GID(0)

شناسه UID برای استفاده در init.
شناسه GID برای استفاده در init.

زمان‌بندی هسته مشخص می‌کند که آیا بار کاری کانتینر به‌عنوان قابل زمان‌بندی روی یک هسته یکسان علامت‌گذاری شود یا خیر. انجام این کار باعث می‌شود زمان‌بند هسته تضمین کند وظایفی که در یک گروه یکسان نیستند هرگز هم‌زمان روی یک هسته اجرا نشوند. این می‌تواند به‌عنوان یک معیار امنیتی اضافی برای جلوگیری از استفاده بار کاری کانتینر از حملات چندرشته‌ای هم‌زمان (cross hyper thread attacks) عمل کند.

تنها مقادیر مجاز 0 و 1 هستند. این گزینه را برای ایجاد یک دامنه زمان‌بندی هسته برای کانتینر روی 1 و برای عدم ایجاد آن روی 0 تنظیم کنید. اگر به‌صراحت تنظیم نشود، هیچ دامنه زمان‌بندی هسته‌ای برای کانتینر ایجاد نخواهد شد.

پیکربندی سامانه پرونده proc برای کانتینر.

نام پرونده proc مورد نظر برای تنظیم را مشخص کنید. نام‌های پرونده موجود مواردی هستند که زیر /proc/PID/ فهرست شده‌اند. نمونه: 
lxc.proc.oom_score_adj = 10

مشخص می‌کند که آیا کانتینر هنگام خاموش شدن نابود شود یا خیر.

تنها مقادیر مجاز 0 و 1 هستند. این گزینه را برابر 1 قرار دهید تا کانتینر هنگام خاموش شدن نابود شود.

بخش شبکه نحوهٔ مجازی‌سازی شبکه در کانتینر را تعیین می‌کند. مجازی‌سازی شبکه در لایهٔ دو عمل می‌کند. به منظور استفاده از مجازی‌سازی شبکه، باید پارامترهایی برای تعریف رابط‌های شبکهٔ کانتینر مشخص شوند. چندین رابط مجازی را می‌توان به یک کانتینر اختصاص داد و استفاده کرد، حتی اگر سیستم فقط یک رابط شبکهٔ فیزیکی داشته باشد.

می‌تواند بدون مقدار برای پاک کردن تمام گزینه‌های شبکهٔ قبلی استفاده شود.
نوع مجازی‌سازی شبکه مورد استفاده برای کانتینر را مشخص می‌کند. باید قبل از هر گزینهٔ دیگری برای دستگاه شبکه مشخص شود. چندین شبکه را می‌توان با استفاده از یک نمایهٔ اضافی i پس از تمام کلیدهای lxc.net.* مشخص کرد. برای نمونه، lxc.net.0.type = veth و lxc.net.1.type = veth دو شبکهٔ مختلف از یک نوع را مشخص می‌کنند. همهٔ کلیدهایی که نمایهٔ یکسان i دارند متعلق به یک شبکه در نظر گرفته می‌شوند. برای نمونه، lxc.net.0.link = br0 متعلق به lxc.net.0.type خواهد بود. در حال حاضر، انواع مختلف مجازی‌سازی می‌توانند موارد زیر باشند:

empty: فقط رابط loopback را ایجاد خواهد کرد.

veth: یک دستگاه جفت اترنت مجازی ایجاد می‌شود که یک سمت آن به کانتینر و سمت دیگر به میزبان اختصاص داده می‌شود. lxc.net.[i].veth.mode حالتی را مشخص می‌کند که والد veth روی میزبان استفاده خواهد کرد. حالت‌های پذیرفته‌شده bridge و router هستند. در صورت تعیین نشدن، حالت پیش‌فرض bridge است. در حالت bridge سمت میزبان به پلی که با گزینهٔ lxc.net.[i].link مشخص شده متصل می‌شود. اگر پیوند پل مشخص نشده باشد، دستگاه جفت veth ایجاد می‌شود اما به هیچ پلی متصل نخواهد شد. در غیر این صورت، پل باید قبل از شروع به کار کانتینر روی سیستم ایجاد شده باشد. lxc هیچ پیکربندی‌ای در خارج از کانتینر را انجام نخواهد داد. در حالت router مسیرهای ایستا روی میزبان برای نشانی‌های IP کانتینر ایجاد می‌شوند که به رابط veth سمت میزبان اشاره می‌کنند. علاوه بر این، مدخل‌های Proxy ARP و Proxy NDP روی رابط veth سمت میزبان برای IPهای درگاه تعریف‌شده در کانتینر اضافه می‌شوند تا کانتینر بتواند به میزبان دسترسی داشته باشد. به‌طور پیش‌فرض، lxc نامی را برای دستگاه شبکه‌ای که متعلق به خارج از کانتینر است انتخاب می‌کند، اما اگر مایلید خودتان این نام را مدیریت کنید، می‌توانید با گزینهٔ lxc.net.[i].veth.pair به lxc بگویید نام خاصی را تنظیم کند (به‌جز برای کانتینرهای بدون امتیاز که در آن‌ها این گزینه بنا به دلایل امنیتی نادیده گرفته می‌شود). مسیرهای ایستا با اشاره به کانتینر را می‌توان با استفاده از گزینه‌های lxc.net.[i].veth.ipv4.route و lxc.net.[i].veth.ipv6.route روی میزبان اضافه کرد. چندین خط چندین مسیر را مشخص می‌کنند. مسیر در قالب x.y.z.t/m است، مانند 192.168.1.0/24. در حالت bridge عضویت VLAN بدون برچسب را می‌توان با گزینهٔ lxc.net.[i].veth.vlan.id تنظیم کرد. این گزینه مقدار ویژهٔ 'none' را می‌پذیرد که نشان می‌دهد درگاه کانتینر باید از VLAN بدون برچسب پیش‌فرض پل حذف شود. گزینهٔ lxc.net.[i].veth.vlan.tagged.id را می‌توان چندین بار برای تعیین عضویت درگاه پل کانتینر در یک یا چند VLAN برچسب‌دار مشخص کرد.

vlan: یک رابط vlan با رابط مشخص‌شده توسط lxc.net.[i].link پیوند داده می‌شود و به کانتینر اختصاص می‌یابد. شناسه vlan با گزینه lxc.net.[i].vlan.id مشخص می‌شود.

macvlan: یک رابط macvlan با رابط مشخص‌شده توسط lxc.net.[i].link پیوند داده می‌شود و به کانتینر اختصاص می‌یابد. lxc.net.[i].macvlan.mode حالتی را مشخص می‌کند که macvlan برای برقراری ارتباط بین macvlanهای مختلف روی همان دستگاه بالادست (upper device) استفاده خواهد کرد. حالت‌های پذیرفته‌شده عبارتند از private، vepa، bridge و passthru. در حالت private، دستگاه هرگز با هیچ دستگاه دیگری روی همان upper_dev ارتباط برقرار نمی‌کند (پیش‌فرض). در حالت vepa، یعنی حالت جدید Virtual Ethernet Port Aggregator (VEPA)، فرض بر این است که پل مجاور تمام فریم‌هایی را که مبدا و مقصد آن‌ها برای درگاه macvlan محلی است، بازمی‌گرداند؛ یعنی پل به عنوان یک بازپخش بازتابی (reflective relay) برپا شده است. فریم‌های پخشی (Broadcast) ورودی از upper_dev در حالت VEPA به تمام رابط‌های macvlan سیلاب (flood) می‌شوند؛ فریم‌های محلی به‌صورت محلی تحویل داده نمی‌شوند. در حالت bridge، رفتار یک پل ساده بین رابط‌های macvlan مختلف روی همان درگاه فراهم می‌شود. فریم‌ها از یک رابط به رابط دیگر به‌طور مستقیم تحویل داده می‌شوند و به بیرون ارسال نمی‌گردند. فریم‌های پخشی به تمام درگاه‌های دیگر پل و رابط خارجی سیلاب می‌شوند، اما زمانی که از یک بازپخش بازتابی برمی‌گردند، دوباره تحویل داده نمی‌شوند. از آنجا که تمام نشانی‌های MAC شناخته‌شده هستند، حالت پل macvlan بر خلاف ماژول bridge نیازی به یادگیری یا STP ندارد. در حالت passthru، تمام فریم‌های دریافت‌شده توسط رابط فیزیکی به رابط macvlan هدایت می‌شوند. تنها یک رابط macvlan در حالت passthru برای یک رابط فیزیکی امکان‌پذیر است.

ipvlan: یک رابط ipvlan با رابط مشخص‌شده توسط lxc.net.[i].link پیوند داده شده و به کانتینر اختصاص می‌یابد. lxc.net.[i].ipvlan.mode حالتی را مشخص می‌کند که ipvlan برای برقراری ارتباط بین ipvlanهای مختلف روی همان دستگاه بالادستی استفاده خواهد کرد. حالت‌های پذیرفته‌شده عبارتند از l3، l3s و l2. پیش‌فرض آن حالت l3 است. در حالت l3، پردازش TX تا سطح L3 روی نمونه پشته متصل به دستگاه وابسته انجام می‌شود و بسته‌ها برای پردازش L2 به نمونه پشته دستگاه والد سوئیچ می‌شوند و پیش از صف‌بندی بسته‌ها روی دستگاه خروجی، مسیریابی از آن نمونه استفاده خواهد شد. در این حالت دستگاه‌های وابسته ترافیک multicast / broadcast را دریافت نکرده و نمی‌توانند ارسال کنند. در حالت l3s، پردازش TX بسیار شبیه به حالت L3 است با این تفاوت که iptables (conn-tracking) در این حالت کار می‌کند و از این رو به صورت متقارن L3 یا (L3s) است. این حالت عملکرد کمی پایین‌تر خواهد داشت اما اهمیتی ندارد، زیرا این حالت را به جای حالت ساده L3 برای کارکرد conn-tracking انتخاب می‌کنید. در حالت l2، پردازش TX روی نمونه پشته متصل به دستگاه وابسته انجام می‌شود و بسته‌ها برای ارسال به خارج، به دستگاه والد سوئیچ و صف‌بندی می‌شوند. در این حالت دستگاه‌های وابسته ترافیک multicast و broadcast (در صورت کاربرد) را نیز RX/TX می‌کنند. lxc.net.[i].ipvlan.isolation حالت جداسازی را مشخص می‌کند. مقادیر جداسازی پذیرفته‌شده عبارتند از bridge، private و vepa. پیش‌فرض آن bridge است. در حالت جداسازی bridge، دستگاه‌های وابسته علاوه بر ارتباط از طریق دستگاه والد می‌توانند بین خود نیز ارتباط برقرار کنند. در حالت جداسازی private، درگاه در حالت خصوصی تنظیم می‌شود؛ یعنی درگاه اجازه ارتباط متقابل بین دستگاه‌های وابسته را نمی‌دهد. در حالت جداسازی vepa، درگاه در حالت VEPA تنظیم می‌شود؛ یعنی درگاه عملکرد سوئیچینگ را طبق آنچه در 802.1Qbg توصیف شده به نهاد بیرونی واگذار می‌کند.

phys: یک رابط از پیش موجود مشخص‌شده توسط lxc.net.[i].link به کانتینر اختصاص می‌یابد.

مشخص کردن عملیات برای شبکه.

up: رابط را فعال می‌کند.

مشخص کردن رابط مورد استفاده برای ترافیک واقعی شبکه.
کنترل می‌کند که آیا مدخل‌های پروکسی همسایه IP لایه ۲ به رابط lxc.net.[i].link برای آدرس‌های IP کانتینر اضافه شوند یا خیر. می‌تواند روی 0 یا 1 تنظیم شود. پیش‌فرض 0 است. هنگام استفاده با آدرس‌های IPv4، مقادیر sysctl زیر باید تنظیم شوند: net.ipv4.conf.[link].forwarding=1 هنگام استفاده با آدرس‌های IPv6، مقادیر sysctl زیر باید تنظیم شوند: net.ipv6.conf.[link].proxy_ndp=1 net.ipv6.conf.[link].forwarding=1
مشخص کردن حداکثر واحد انتقال (MTU) برای این رابط.
نام رابط به صورت پویا تخصیص داده می‌شود، اما اگر به دلیل اینکه پرونده‌های پیکربندی مورد استفاده توسط کانتینر از یک نام عمومی مانند eth0 استفاده می‌کنند نام دیگری نیاز باشد، این گزینه نام رابط را در کانتینر تغییر می‌دهد.
آدرس mac رابط به طور پیش‌فرض به صورت پویا به رابط مجازی اختصاص می‌یابد، اما در برخی موارد، برای حل تداخل آدرس mac یا داشتن همیشگی یک آدرس link-local ipv6 یکسان به این گزینه نیاز است. هر "x" در آدرس با مقدار تصادفی جایگزین خواهد شد، این ویژگی امکان تنظیم قالب‌های hwaddr را فراهم می‌کند.
مشخص کردن آدرس ipv4 برای اختصاص به رابط مجازی‌سازی‌شده. چندین خط آدرس‌های ipv4 متعددی را مشخص می‌کنند. آدرس در قالب x.y.z.t/m است، مانند 192.168.1.123/24. می‌توانید به صورت اختیاری آدرس پخش (broadcast) را پس از آدرس IP مشخص کنید، مانند 192.168.1.123/24 255.255.255.255. در غیر این صورت به طور خودکار از آدرس IP محاسبه می‌شود.
مشخص کردن آدرس ipv4 برای استفاده به عنوان درگاه داخل کانتینر. آدرس در قالب x.y.z.t است، مانند 192.168.1.123. همچنین می‌تواند مقدار ویژه auto را داشته باشد، به این معنی که آدرس اصلی را از رابط پل (مشخص‌شده توسط گزینه lxc.net.[i].link) گرفته و از آن به عنوان درگاه استفاده کند. auto تنها هنگام استفاده از انواع شبکه veth، macvlan و ipvlan در دسترس است. همچنین می‌تواند مقدار ویژه dev داشته باشد، به این معنی که درگاه پیش‌فرض را به عنوان یک مسیر دستگاه (device route) تنظیم کند. این مورد در اصل برای استفاده در حالت‌های شبکه لایه ۳، مانند IPVLAN است.
نشانی ipv6 اختصاص‌یافته به رابط مجازی‌سازی‌شده را تعیین می‌کند. چندین خط نشانی‌های ipv6 متعددی را تعیین می‌کنند. نشانی در قالب x::y/m است، مانند 2003:db8:1:0:214:1234:fe0b:3596/64
نشانی ipv6 برای استفاده به عنوان دروازه (gateway) داخل کانتینر را تعیین می‌کند. نشانی در قالب x::y است، مانند 2003:db8:1:0::1 همچنین می‌تواند مقدار ویژه auto را داشته باشد، به این معنی که نشانی اصلی از رابط پل (که با گزینه lxc.net.[i].link مشخص شده) گرفته شده و به عنوان دروازه استفاده شود. auto تنها هنگام استفاده از نوع‌های شبکه veth، macvlan و ipvlan در دسترس است. همچنین می‌تواند مقدار ویژه dev را داشته باشد، به این معنی که دروازه پیش‌فرض به عنوان یک مسیر دستگاه (device route) تنظیم شود. این حالت عمدتاً برای استفاده در حالت‌های شبکه لایه ۳ مانند IPVLAN است.
یک گزینه پیکربندی برای تعیین اسکریپتی اضافه می‌کند که پس از ایجاد و پیکربندی شبکه مورد استفاده از سمت میزبان اجرا شود.

علاوه بر اطلاعات موجود برای تمام قلاب‌ها (hooks)، اطلاعات زیر به اسکریپت ارائه می‌شود:

•
LXC_HOOK_TYPE: نوع قلاب. مقدار آن 'up' یا 'down' است.
•
LXC_HOOK_SECTION: نوع بخش 'net'.
•
LXC_NET_TYPE: نوع شبکه. یکی از نوع‌های معتبر شبکه فهرست‌شده در اینجا (مانند 'vlan' ،'macvlan' ،'ipvlan' ،'veth').
•
LXC_NET_PARENT: دستگاه والد روی میزبان. این مقدار تنها برای نوع‌های شبکه 'mavclan' ،'veth' و 'phys' تنظیم می‌شود.
•
LXC_NET_PEER: نام دستگاه همتا (peer) روی میزبان. این مقدار تنها برای نوع‌های شبکه 'veth' تنظیم می‌شود. توجه داشته باشید این اطلاعات تنها زمانی در دسترس است که lxc.hook.version برابر با 1 تنظیم شده باشد.

اینکه این اطلاعات در قالب متغیرهای محیطی ارائه شوند یا به عنوان آرگومان‌های اسکریپت، به مقدار lxc.hook.version بستگی دارد. اگر روی 1 تنظیم شده باشد، اطلاعات در قالب متغیرهای محیطی ارائه می‌شوند. اگر روی 0 تنظیم شده باشد، اطلاعات به عنوان آرگومان به اسکریپت داده می‌شوند.

خروجی استاندارد (Standard output) اسکریپت در سطح دیباگ (debug) ثبت می‌شود. خطای استاندارد (Standard error) ثبت نمی‌شود، اما قلاب می‌تواند با هدایت خطای استاندارد خود به خروجی استاندارد آن را ضبط کند.

یک گزینه پیکربندی برای تعیین اسکریپتی که باید پیش از نابود کردن شبکه استفاده‌شده از سمت میزبان اجرا شود، اضافه می‌کند.

علاوه بر اطلاعات موجود برای تمام قلاب‌ها، اطلاعات زیر نیز به اسکریپت ارائه می‌شود:

•
LXC_HOOK_TYPE: نوع قلاب. این مقدار یا 'up' است یا 'down'.
•
LXC_HOOK_SECTION: نوع بخش 'net'.
•
LXC_NET_TYPE: نوع شبکه. این یکی از انواع شبکه معتبر فهرست‌شده در اینجاست (مانند 'vlan' ،'macvlan' ،'ipvlan' ،'veth').
•
LXC_NET_PARENT: دستگاه والد روی میزبان. این مقدار تنها برای انواع شبکه
•
LXC_NET_PEER: نام دستگاه همتا روی میزبان. این مقدار تنها برای انواع شبکه است که lxc.hook.version روی 1 تنظیم شده باشد.

اینکه این اطلاعات در قالب متغیرهای محیطی یا به عنوان آرگومان به اسکریپت داده شوند، به مقدار lxc.hook.version بستگی دارد. اگر روی 1 تنظیم شده باشد، اطلاعات در قالب متغیرهای محیطی ارائه می‌شوند. اگر روی 0 تنظیم شده باشد، اطلاعات به عنوان آرگومان به اسکریپت منتقل می‌شوند.

خروجی استاندارد اسکریپت در سطح اشکال‌زدایی (debug) ثبت می‌شود. خطای استاندارد ثبت نمی‌شود، اما با بازهدایت خطای استاندارد به خروجی استاندارد درون قلاب، می‌توان آن را دریافت کرد.

برای جداسازی دقیق‌تر، کانتینر می‌تواند نمونه خصوصی خود را از pseudo tty داشته باشد.

در صورت تنظیم، کانتینر نمونه جدیدی از pseudo tty خواهد داشت که آن را برایش اختصاصی می‌کند. این مقدار حداکثر تعداد pseudo ttyهای مجاز برای یک نمونه pty را مشخص می‌کند (این محدودیت هنوز پیاده‌سازی نشده است).

اگر کانتینر با یک سیستم پرونده ریشه پیکربندی شده باشد و پرونده inittab برای استفاده از کنسول برپا شده باشد، ممکن است بخواهید مشخص کنید که خروجی این کنسول به کجا برود.

تنظیم این گزینه به liblxc دستور می‌دهد تا یک ringbuffer در حافظه تخصیص دهد. خروجی کنسول کانتینر در این ringbuffer نوشته خواهد شد. توجه داشته باشید که ringbuffer باید حداقل به اندازه اندازه استاندارد یک صفحه (page size) باشد. هنگام ارسال مقداری کوچکتر از اندازه یک صفحه، liblxc یک ringbuffer به اندازه یک صفحه تخصیص می‌دهد. اندازه صفحه معمولاً 4KB است. کلیدواژه 'auto' باعث می‌شود liblxc یک ringbuffer به اندازه 128KB تخصیص دهد. هنگام مشخص کردن دستی اندازه برای ringbuffer، مقدار پس از تبدیل به بایت باید توانی از ۲ باشد. پیشوندهای اندازه معتبر عبارتند از 'KB'، 'MB'، 'GB'. (توجه داشته باشید که تمام تبدیل‌ها بر اساس مضارب ۱۰۲۴ هستند. یعنی 'KB' == 'KiB'، 'MB' == 'MiB'، 'GB' == 'GiB'. علاوه بر این، بزرگی و کوچکی حروف پسوند نادیده گرفته می‌شود؛ یعنی با 'kB'، 'KB' و 'Kb' به طور یکسان برخورد می‌شود.)
تنظیم این گزینه به liblxc دستور می‌دهد تا محدودیتی برای اندازه پرونده لاگ کنسول مشخص‌شده در lxc.console.logfile اعمال کند. توجه داشته باشید که اندازه پرونده لاگ باید حداقل به اندازه اندازه استاندارد یک صفحه باشد. هنگام ارسال مقداری کوچکتر از اندازه یک صفحه، liblxc اندازه پرونده لاگ را به اندازه یک صفحه تنظیم می‌کند. اندازه صفحه معمولاً 4KB است. کلیدواژه 'auto' باعث می‌شود liblxc محدودیت 128KB را روی پرونده لاگ اعمال کند. هنگام مشخص کردن دستی اندازه برای پرونده لاگ، مقدار پس از تبدیل به بایت باید توانی از ۲ باشد. پیشوندهای اندازه معتبر عبارتند از 'KB'، 'MB'، 'GB'. (توجه داشته باشید که تمام تبدیل‌ها بر اساس مضارب ۱۰۲۴ هستند. یعنی 'KB' == 'KiB'، 'MB' == 'MiB'، 'GB' == 'GiB'. علاوه بر این، بزرگی و کوچکی حروف پسوند نادیده گرفته می‌شود؛ یعنی با 'kB'، 'KB' و 'Kb' به طور یکسان برخورد می‌شود.) اگر کاربران بخواهند ringbuffer کنسول را روی دیسک آینه‌سازی (mirror) کنند، باید lxc.console.size را برابر با lxc.console.buffer.size تنظیم کنند.
مسیر پرونده‌ای را که خروجی کنسول در آن نوشته می‌شود مشخص می‌کند. توجه داشته باشید که برخلاف پرونده گزارش ringbuffer روی دیسک، حجم این پرونده پیوسته افزایش می‌یابد و در صورت عدم چرخش (rotate) و پاکسازی، می‌تواند دیسک کاربر را پر کند. این مشکل را می‌توان با استفاده از گزینه‌های ringbuffer در حافظه یعنی lxc.console.buffer.size و lxc.console.buffer.logfile برطرف کرد.
تعیین می‌کند که آیا پرونده گزارش کنسول مشخص‌شده در lxc.console.logfile چرخش یابد یا خیر. کاربران می‌توانند یک درخواست API برای چرخش پرونده گزارش ارسال کنند. توجه داشته باشید که پرونده گزارش پیشین، همان نام پرونده اصلی را به همراه پسوند «.1» خواهد داشت. کاربرانی که مایل به جلوگیری از پر شدن دیسک توسط پرونده گزارش کنسول هستند باید آن را چرخش داده و در صورت عدم نیاز حذف کنند. این مشکل را می‌توان با استفاده از گزینه‌های ringbuffer در حافظه یعنی lxc.console.buffer.size و lxc.console.buffer.logfile نیز برطرف کرد.
مسیر دستگاهی را که کنسول به آن متصل می‌شود مشخص می‌کند. کلیدواژه 'none' کنسول را غیرفعال می‌کند. توجه داشته باشید، هنگام تعیین 'none' و ایجاد یک نود دستگاه برای کنسول درون کانتینر در /dev/console یا bind-mount کردن /dev/console میزبان به درون کانتینر در /dev/console، کانتینر دسترسی مستقیم به /dev/console میزبان خواهد داشت. این حالت در صورت داشتن دسترسی نوشتن کانتینر روی دستگاه خطرناک است و باید با احتیاط استفاده شود.

این گزینه زمانی مفید است که کانتینر با یک سیستم‌پرونده ریشه پیکربندی شده باشد و پرونده inittab برای اجرای getty روی ttyها تنظیم شده باشد. این گزینه تعداد ttyهای در دسترس برای کانتینر را مشخص می‌کند. تعداد gettyها در پرونده inittab کانتینر نباید بیشتر از تعداد ttyهای مشخص‌شده در این گزینه باشد، در غیر این صورت نشست‌های getty اضافی از بین رفته و مکرراً بازتولید می‌شوند که باعث ایجاد پیام‌های آزاردهنده در کنسول یا /var/log/messages می‌شود.

مشخص کردن تعداد ttyهای در دسترس برای کانتینر.

کنسول‌های LXC از طریق Unix98 PTYهای ایجاد شده روی میزبان تامین می‌شوند و روی دستگاه‌های مورد انتظار در کانتینر bind-mount می‌گردند. به‌صورت پیش‌فرض، آن‌ها روی /dev/console و /dev/ttyN متصل می‌شوند (bind-mount). این موضوع می‌تواند مانع ارتقای بسته‌ها در مهمان شود. بنابراین می‌توانید مسیر یک دایرکتوری را (زیر /dev) مشخص کنید که LXC پرونده‌ها را در آن ایجاد کرده و روی آن‌ها bind-mount انجام دهد. این پرونده‌ها سپس به‌صورت پیوند نمادین (symbolic link) به /dev/console و /dev/ttyN متصل خواهند شد. به این ترتیب ارتقای بسته با موفقیت انجام می‌شود چون امکان حذف و جایگزینی پیوندهای نمادین وجود دارد.

مشخص کردن یک دایرکتوری زیر /dev برای ایجاد دستگاه‌های کنسول کانتینر. توجه داشته باشید که LXC هرگونه bind-mount یا گره دستگاه (device node) برای /dev/console را به داخل این دایرکتوری منتقل می‌کند.

به‌طور پیش‌فرض، lxc چند پیوند نمادین (fd,stdin,stdout,stderr) در دایرکتوری /dev کانتینر ایجاد می‌کند اما مدخل‌های گره دستگاه را به‌طور خودکار ایجاد نمی‌کند. این موضوع اجازه می‌دهد /dev کانتینر بر اساس نیاز در rootfs کانتینر تنظیم شود. اگر lxc.autodev روی 1 تنظیم شده باشد، پس از سوار کردن rootfs کانتینر، LXC یک tmpfs تازه را زیر /dev سوار می‌کند (به‌طور پیش‌فرض محدود به 500K، مگر اینکه در lxc.autodev.tmpfs.size تعریف شده باشد) و مجموعه‌ای حداقلی از دستگاه‌های اولیه را درون آن قرار می‌دهد. این عمل عموماً هنگام راه‌اندازی کانتینری که شامل یک "init" مبتنی بر "systemd" است الزامی است، اما در مواقع دیگر ممکن است اختیاری باشد. دستگاه‌های اضافی در دایرکتوری /dev کانتینر می‌توانند با استفاده از قلاب lxc.hook.autodev ایجاد شوند.

این گزینه را روی 0 تنظیم کنید تا از سوار کردن و مقداردهی یک /dev حداقلی توسط LXC هنگام شروع کانتینر جلوگیری شود.
این گزینه را برای تعیین اندازه tmpfs مربوط به /dev تنظیم کنید. مقدار پیش‌فرض 500000 (500K) است. اگر پارامتر استفاده شود اما بدون مقدار باشد، مقدار پیش‌فرض اعمال می‌شود.

بخش نقاط اتصال، مکان‌های مختلفی را که باید سوار شوند مشخص می‌کند. این نقاط اتصال برای کانتینر خصوصی خواهند بود و توسط فرآیندهای در حال اجرا در خارج از کانتینر قابل مشاهده نخواهند بود. این ویژگی برای مثال جهت سوار کردن /etc، /var یا /home مفید است.

نکته - LXC به‌طور کلی اطمینان حاصل می‌کند که مقصدهای اتصال و منابع نسبی bind-mount به‌درستی درون ریشه کانتینر محدود شده‌اند، تا از حملات مربوط به سوار کردن دوباره روی دایرکتوری‌ها و پرونده‌های میزبان جلوگیری شود. (پیوندهای نمادین در منابع اتصال مطلق نادیده گرفته می‌شوند) با این حال، اگر پیکربندی کانتینر ابتدا دایرکتوری‌ای را که تحت کنترل کاربر کانتینر است (مانند /home/joe) در یک path درون کانتینر سوار کند، و سپس زیر path اتصالی انجام دهد، در این صورت یک حمله TOCTTOU امکان‌پذیر خواهد بود که در آن کاربر کانتینر یک پیوند نمادین را زیر دایرکتوری خانگی خود در زمان مناسب تغییر دهد.

مکان یک پرونده را در قالب fstab مشخص کنید که حاوی اطلاعات اتصال است. مکان مقصد اتصال می‌تواند و در بیشتر موارد باید یک مسیر نسبی باشد، که نسبت به ریشه سوار شده کانتینر سنجیده خواهد شد. به عنوان مثال، 
proc proc proc nodev,noexec,nosuid 0 0

یک سیستم پرونده proc را زیر /proc کانتینر سوار می‌کند، بدون توجه به اینکه سیستم پرونده ریشه از کجا می‌آید. این روش در برابر سیستم‌های پرونده مبتنی بر دستگاه بلوکی و همچنین شبیه‌سازی کانتینر مقاوم است.

توجه داشته باشید که هنگام سوار کردن یک سیستم پرونده از یک پرونده تصویر (image file) یا دستگاه بلوکی، فیلد سوم (fs_vfstype) نمی‌تواند مانند mount(8) برابر با auto باشد، بلکه باید به‌طور صریح مشخص شود.

یک نقطه اتصال متناظر با یک خط در قالب fstab را مشخص می‌کند. علاوه بر این lxc از انتشار اتصال (mount propagation) مانند rshared یا rprivate پشتیبانی کرده و سه گزینه اتصال اضافی می‌افزاید. optional اگر اتصال کار نکرد، با شکست مواجه نشود. create=dir یا create=file برای ایجاد دایرکتوری (یا پرونده) در زمان متصل شدن نقطه مورد نظر. relative مسیر منبع به صورت نسبی نسبت به ریشه کانتینر متصل‌شده در نظر گرفته می‌شود. به عنوان مثال، 
dev/null proc/kcore none bind,relative 0 0

مقدار dev/null را به ${LXC_ROOTFS_MOUNT}/dev/null بسط داده و آن را به proc/kcore در داخل کانتینر متصل می‌کند.

مشخص می‌کند کدام سیستم‌های پرونده استاندارد هسته باید به طور خودکار متصل شوند. این گزینه پیکربندی را به طور چشمگیری ساده می‌کند. سیستم‌های پرونده عبارتند از:
•
proc:mixed (یا proc): اتصال /proc به صورت خواندن-نوشتن، اما اتصال مجدد /proc/sys و /proc/sysrq-trigger به صورت فقط-خواندنی به منظور امنیت / جداسازی کانتینر.
•
proc:rw: اتصال /proc به صورت خواندن-نوشتن
•
sys:mixed (یا sys): اتصال /sys به صورت فقط-خواندنی اما با قابلیت نوشتن برای /sys/devices/virtual/net.
•
sys:ro: اتصال /sys به صورت فقط-خواندنی به منظور امنیت / جداسازی کانتینر.
•
sys:rw: سوار کردن /sys به صورت خواندن-نوشتن
•
cgroup:mixed: یک tmpfs را روی /sys/fs/cgroup سوار می‌کند، دایرکتوری‌هایی برای تمام سلسله‌مراتب‌هایی که کانتینر به آن‌ها افزوده شده می‌سازد، زیردایرکتوری‌هایی در آن سلسله‌مراتب‌ها با نام cgroup ایجاد می‌کند، و cgroup اختصاصی کانتینر را به صورت bind-mount درون آن دایرکتوری سوار می‌کند. کانتینر قادر به نوشتن در دایرکتوری cgroup اختصاصی خود خواهد بود، اما نه در والدها، چرا که آن‌ها مجدداً به صورت فقط‌خواندنی سوار می‌شوند.
•
cgroup:mixed:force: گزینهٔ force باعث می‌شود LXC تحت هر شرایطی عملیات سوار کردن cgroup را برای کانتینر انجام دهد. در غیر این صورت، مشابه cgroup:mixed است. این گزینه عمدتاً زمانی کاربرد دارد که فضاهای نام cgroup فعال باشند، جایی که LXC به طور معمول سوار کردن cgroupها را به فایل اجرایی init کانتینر واگذار می‌کند، زیرا انجام این کار کاملاً ایمن است.
•
cgroup:ro: مشابه cgroup:mixed است، اما همه‌چیز به صورت فقط‌خواندنی سوار خواهد شد.
•
cgroup:ro:force: گزینهٔ force باعث می‌شود LXC تحت هر شرایطی عملیات سوار کردن cgroup را برای کانتینر انجام دهد. در غیر این صورت، مشابه cgroup:ro است. این گزینه عمدتاً زمانی کاربرد دارد که فضاهای نام cgroup فعال باشند، جایی که LXC به طور معمول سوار کردن cgroupها را به فایل اجرایی init کانتینر واگذار می‌کند، زیرا انجام این کار کاملاً ایمن است.
•
cgroup:rw: مشابه cgroup:mixed است، اما همه‌چیز به صورت خواندن-نوشتن سوار خواهد شد. توجه داشته باشید که مسیرهای منتهی به cgroup اختصاصی کانتینر قابل نوشتن خواهند بود، اما یک سیستم پروندهٔ cgroup نیستند و صرفاً بخشی از tmpfs در /sys/fs/cgroup به شمار می‌روند.
•
cgroup:rw:force: گزینهٔ force باعث می‌شود LXC تحت هر شرایطی عملیات سوار کردن cgroup را برای کانتینر انجام دهد. در غیر این صورت، مشابه cgroup:rw است. این گزینه عمدتاً زمانی کاربرد دارد که فضاهای نام cgroup فعال باشند، جایی که LXC به طور معمول سوار کردن cgroupها را به فایل اجرایی init کانتینر واگذار می‌کند، زیرا انجام این کار کاملاً ایمن است.
•
cgroup (بدون مشخص‌کننده): در صورتی که کانتینر قابلیت CAP_SYS_ADMIN را حفظ کند، پیش‌فرض cgroup:rw و در غیر این صورت cgroup:mixed است.
•
cgroup-full:mixed: یک tmpfs روی /sys/fs/cgroup سوار می‌کند، برای تمام سلسله‌مراتب‌هایی که کانتینر به آن‌ها افزوده شده دایرکتوری می‌سازد، سلسله‌مراتب‌ها را از میزبان به کانتینر bind-mount کرده و همه‌چیز را به‌جز cgroup خود کانتینر فقط‌خواندنی می‌کند. توجه داشته باشید که در مقایسه با cgroup، که تمام مسیرهای منتهی به cgroup خود کانتینر صرفاً دایرکتوری‌های ساده در tmpfs زیرین هستند، در اینجا /sys/fs/cgroup/$hierarchy شامل سلسله‌مراتب کامل cgroup میزبان خواهد بود، اگرچه خارج از cgroup خود کانتینر فقط‌خواندنی است. این کار ممکن است اطلاعات نسبتاً زیادی را به کانتینر درز دهد.
•
cgroup-full:mixed:force: گزینه force باعث می‌شود LXC تحت هر شرایطی عملیات سوار کردن cgroup را برای کانتینر انجام دهد. در غیر این صورت شبیه به cgroup-full:mixed است. این ویژگی عمدتاً زمانی مفید است که فضاهای نام cgroup فعال باشند؛ جایی که LXC در حالت عادی سوار کردن cgroupها را به باینری init کانتینر واگذار می‌کند، چرا که انجام آن کاملاً امن است.
•
cgroup-full:ro: شبیه به cgroup-full:mixed، اما همه‌چیز به‌صورت فقط‌خواندنی سوار خواهد شد.
•
cgroup-full:ro:force: گزینه force باعث می‌شود LXC تحت هر شرایطی عملیات سوار کردن cgroup را برای کانتینر انجام دهد. در غیر این صورت شبیه به cgroup-full:ro است. این ویژگی عمدتاً زمانی مفید است که فضاهای نام cgroup فعال باشند؛ جایی که LXC در حالت عادی سوار کردن cgroupها را به باینری init کانتینر واگذار می‌کند، چرا که انجام آن کاملاً امن است.
•
cgroup-full:rw: مشابه cgroup-full:mixed، اما همه‌چیز به‌صورت خواندن-نوشتن سوار خواهد شد. توجه داشته باشید که در این حالت، کانتینر ممکن است از cgroup خود خارج شود. (همچنین توجه داشته باشید که اگر کانتینر از CAP_SYS_ADMIN پشتیبانی کند و بتواند سامانه پرونده cgroup را خودش سوار کند، ممکن است در هر صورت این کار را انجام دهد.)
•
cgroup-full:rw:force: گزینه force باعث می‌شود LXC در هر شرایطی عملیات سوار کردن cgroup را برای کانتینر انجام دهد. در غیر این صورت مشابه cgroup-full:rw است. این گزینه عمدتاً زمانی مفید است که فضاهای نام cgroup فعال باشند، جایی که LXC معمولاً سوار کردن cgroupها را به باینری init کانتینر واگذار می‌کند، زیرا انجام آن کاملاً ایمن است.
•
cgroup-full (بدون مشخص‌کننده): در صورتی که کانتینر قابلیت CAP_SYS_ADMIN را حفظ کند، پیش‌فرض روی cgroup-full:rw است، در غیر این صورت cgroup-full:mixed.

اگر فضاهای نام cgroup فعال باشند، هرگونه درخواست سوار کردن خودکار cgroup نادیده گرفته خواهد شد، زیرا کانتینر می‌تواند سامانه‌های پرونده را خودش سوار کند و سوار کردن خودکار ممکن است init کانتینر را دچار سردرگمی کند.

توجه داشته باشید که اگر سوار کردن خودکار سامانه پرونده cgroup فعال باشد، tmpfs در مسیر /sys/fs/cgroup همیشه به‌صورت خواندن-نوشتن سوار خواهد شد (اما برای حالت‌های :mixed و :ro، سلسله‌مراتب‌های مجزا، /sys/fs/cgroup/$hierarchy، به‌صورت فقط-خواندنی خواهند بود). این کار برای دور زدن یک رفتار خاص در دستور mountall(8) اوبونتو است که اگر /sys/fs/cgroup به‌صورت فقط-خواندنی سوار شده باشد و کانتینر به دلیل نداشتن CAP_SYS_ADMIN نتواند آن را مجدداً به‌صورت خواندن-نوشتن سوار کند، باعث می‌شود کانتینرها در زمان بوت منتظر ورودی کاربر بمانند.

نمونه‌ها:

lxc.mount.auto = proc sys cgroup
lxc.mount.auto = proc:rw sys:rw cgroup-full:rw

سیستم پرونده ریشه کانتینر می‌تواند متفاوت از سیستم پرونده میزبان باشد.

سیستم پرونده ریشه را برای کانتینر مشخص می‌کند. می‌تواند یک پرونده ایمیج، یک دایرکتوری یا یک دستگاه بلوکی باشد. در صورت مشخص نشدن، کانتینر سیستم پرونده ریشه خود را با میزبان به اشتراک می‌گذارد.

برای کانتینرهای مبتنی بر دایرکتوری یا دستگاه بلوکی ساده، می‌توان از یک مسیر استفاده کرد. اگر rootfs مبتنی بر یک دستگاه nbd باشد، عبارت nbd:file:1 مشخص می‌کند که file باید به یک دستگاه nbd متصل شود، و پارتیشن ۱ باید به عنوان rootfs سوار شود. nbd:file مشخص می‌کند که خود دستگاه nbd باید سوار شود. overlayfs:/lower:/upper مشخص می‌کند که rootfs باید یک overlay باشد که در آن /upper به‌صورت خواندن-نوشتن روی یک سوارشدگی فقط‌خواندنی از /lower سوار می‌شود. برای overlay می‌توان چندین دایرکتوری /lower مشخص کرد. loop:/file به lxc اعلام می‌کند /file را به یک دستگاه loop متصل کرده و دستگاه loop را سوار کند.

محل اتصال بازگشتی (recursive bind) برای lxc.rootfs.path پیش از تغییر ریشه (pivot). این مورد برای اطمینان از موفقیت فراخوان سیستمی pivot_root(8) است. هر دایرکتوری کفایت می‌کند و مقدار پیش‌فرض عموماً کارساز خواهد بود.
گزینه‌های اضافی سوار کردن (mount options) را هنگام سوار کردن rootfs مشخص می‌کند. قالب گزینه‌های سوار کردن مطابق با قالب مورد استفاده در fstab است. علاوه بر این، LXC از گزینه سوار کردن سفارشی idmap= پشتیبانی می‌کند. این گزینه می‌تواند برای واداشتن LXC به ایجاد یک سوارشدگی با نگاشت شناسه (idmapped mount) برای rootfs کانتینر استفاده شود. این قابلیت زمانی مفید است که کاربر مایل به اجرای بازگشتی chown روی rootfs کانتینر برای تطبیق با idmapping فضای‌نام کاربری (user namespace) مورد استفاده کانتینر نباشد. در عوض می‌توان از یک idmapped mount برای مدیریت آن استفاده کرد. آرگومان برای idmap= می‌تواند یک مسیر اشاره‌کننده به پرونده فضای‌نام کاربری باشد که LXC آن را باز کرده و برای نگاشت شناسه rootfs استفاده کند، یا مقدار ویژه "container" باشد که به LXC اعلام می‌کند از فضای‌نام کاربری کانتینر برای نگاشت شناسه rootfs استفاده کند.
این مقدار را روی 0 قرار دهید تا مشخص شود LXC فضای ذخیره‌سازی کانتینر را مدیریت نمی‌کند؛ در این صورت LXC فضای ذخیره‌سازی کانتینر را تغییر نخواهد داد. پیش‌فرض 1 است.

بخش گروه کنترل شامل پیکربندی زیرسیستم‌های مختلف است. lxc صحت نام زیرسیستم را بررسی نمی‌کند. این موضوع این عیب را دارد که خطاهای پیکربندی تا زمان شروع کانتینر شناسایی نمی‌شوند، اما این مزیت را دارد که امکان استفاده از هر زیرسیستم دیگری در آینده را فراهم می‌کند.

پیاده‌سازی هسته برای cgroups در طول سال‌ها به طور چشمگیری تغییر کرده است. با لینوکس 4.5، پشتیبانی از یک سیستم پرونده جدید cgroup اضافه شد که معمولاً با عنوان «cgroup2» یا «سلسله‌مراتب یکپارچه» (unified hierarchy) شناخته می‌شود. از آن زمان به بعد، سیستم پرونده قدیمی cgroup معمولاً با عنوان «cgroup1» یا «سلسله‌مراتب‌های موروثی» (legacy hierarchies) شناخته می‌شود. لطفاً برای توضیح دقیق تفاوت‌های بین این دو نسخه، صفحه راهنمای cgroups را مشاهده کنید.

LXC تنظیمات مربوط به سلسله‌مراتب موروثی و سلسله‌مراتب یکپارچه را با استفاده از پیشوندهای کلید پیکربندی مختلف متمایز می‌کند. برای تغییر تنظیمات کنترل‌کننده‌ها در سلسله‌مراتب موروثی باید از پیشوند کلید lxc.cgroup. استفاده شود و به منظور تغییر تنظیمات برای یک کنترل‌کننده در سلسله‌مراتب یکپارچه، باید کلید lxc.cgroup2. به کار رود. توجه داشته باشید که LXC تنظیمات lxc.cgroup. را در سیستم‌هایی که تنها از سلسله‌مراتب یکپارچه استفاده می‌کنند نادیده می‌گیرد. برعکس، این برنامه گزینه‌های lxc.cgroup2. را در سیستم‌هایی که فقط از سلسله‌مراتب‌های موروثی استفاده می‌کنند نادیده خواهد گرفت. پشتیبانی از lxc.cgroup. (سلسله‌مراتب موروثی و پیوندی) متوقف شده است.

در اصل، یک سلسله‌مراتب cgroup راهکاری برای سازماندهی سلسله‌مراتبی فرایندها است. معمولاً در یک سلسله‌مراتب cgroup یک یا چند «کنترل‌کننده» فعال هستند. یک «کنترل‌کننده» در سلسله‌مراتب cgroup معمولاً مسئول توزیع نوع خاصی از منابع سیستم در طول سلسله‌مراتب است. کنترل‌کننده‌ها شامل کنترل‌کننده «pids»، کنترل‌کننده «cpu»، کنترل‌کننده «memory» و موارد دیگر می‌شوند. با این حال، برخی از کنترل‌کننده‌ها در دسته توزیع منابع سیستم قرار نمی‌گیرند؛ در عوض اغلب به عنوان کنترل‌کننده‌های «کاربردی» (utility) شناخته می‌شوند. یکی از کنترل‌کننده‌های کاربردی، کنترل‌کننده دستگاه (device) است. این کنترل‌کننده به جای توزیع منابع سیستم، امکان مدیریت دسترسی به دستگاه را فراهم می‌کند.

در سلسله‌مراتب موروثی، کنترل‌کننده دستگاه مانند بیشتر کنترل‌کننده‌های دیگر به صورت مجموعه‌ای از پرونده‌ها پیاده‌سازی شده بود که امکان نوشتن روی آن‌ها وجود داشت. این پرونده‌ها «devices.allow» و «devices.deny» نام داشتند. کنترل‌کننده دستگاه موروثی امکان پیاده‌سازی هر دو حالت «فهرست‌های مجاز» (allowlists) و «فهرست‌های ممنوعه» (denylists) را فراهم می‌کرد.

یک فهرست مجاز، برنامه‌ای برای دستگاه است که به صورت پیش‌فرض دسترسی به تمام دستگاه‌ها را مسدود می‌کند. به منظور دسترسی به دستگاه‌های خاص، باید «قوانین مجاز» (allow rules) برای دستگاه‌ها یا کلاس‌های دستگاه خاصی تعیین شوند. در مقابل، یک فهرست ممنوعه برنامه‌ای برای دستگاه است که به صورت پیش‌فرض امکان دسترسی به تمام دستگاه‌ها را می‌دهد. به منظور محدود کردن دسترسی به دستگاه‌های خاص، باید «قوانین ممنوع» (deny rules) برای دستگاه‌ها یا کلاس‌های دستگاه مشخصی تعیین شوند.

در سلسله‌مراتب یکپارچه cgroup پیاده‌سازی کنترل‌کننده دستگاه کاملاً تغییر کرده است. به جای پرونده‌هایی برای خواندن و نوشتن، یک برنامه eBPF از نوع BPF_PROG_TYPE_CGROUP_DEVICE می‌تواند به یک cgroup پیوست شود. با وجود اینکه پیاده‌سازی هسته کاملاً تغییر کرده است، LXC تلاش می‌کند تا همان مفاهیم در cgroup موروثی دستگاه و کنترل‌کننده یکپارچه دستگاه مبتنی بر eBPF دنبال شوند. پاراگراف‌های زیر مفاهیم کنترل‌کننده یکپارچه دستگاه مبتنی بر eBPF را توضیح می‌دهند.

همان‌طور که اشاره شد، قالب تعیین قوانین دستگاه برای کنترل‌کننده یکپارچه دستگاه مبتنی بر eBPF مانند کنترل‌کننده موروثی دستگاه cgroup است؛ فقط پیشوند کلید پیکربندی تغییر کرده است. به طور مشخص، قوانین دستگاه برای کنترل‌کننده موروثی دستگاه cgroup از طریق lxc.cgroup.devices.allow و lxc.cgroup.devices.deny مشخص می‌شوند، در حالی که برای کنترل‌کننده دستگاه مبتنی بر eBPF در cgroup2 باید از lxc.cgroup2.devices.allow و lxc.cgroup2.devices.deny استفاده شود.

•
یک قاعده دستگاه‌های فهرست سیاه (denylist) 
lxc.cgroup2.devices.deny = a

باعث می‌شود LXC به هسته دستور دهد تا دسترسی به همه دستگاه‌ها را به‌طور پیش‌فرض مسدود کند. برای اعطای دسترسی به دستگاه‌ها، قواعد مجاز کردن دستگاه باید از طریق کلید lxc.cgroup2.devices.allow اضافه شوند. به این حالت برنامه دستگاه‌های «فهرست سفید» (allowlist) گفته می‌شود.

•
یک قاعده دستگاه‌های فهرست سفید (allowlist) 
lxc.cgroup2.devices.allow = a

باعث می‌شود LXC به هسته دستور دهد تا دسترسی به همه دستگاه‌ها را به‌طور پیش‌فرض مجاز کند. برای منع دسترسی به دستگاه‌ها، قواعد رد دستگاه باید از طریق کلید lxc.cgroup2.devices.deny اضافه شوند. به این حالت برنامه دستگاه‌های «فهرست سیاه» (denylist) گفته می‌شود.

•
مشخص کردن هر یک از دو قاعده ذکر شده در بالا باعث پاک شدن تمام قواعد قبلی می‌شود، یعنی فهرست دستگاه‌ها بازنشانی خواهد شد.
•
هنگامی که یک برنامه فهرست سفید درخواست می‌شود، یعنی دسترسی به همه دستگاه‌ها به‌طور پیش‌فرض مسدود است، قواعد رد خاص برای دستگاه‌های منفرد یا رده‌های دستگاه نادیده گرفته می‌شوند.
•
هنگامی که یک برنامه فهرست سیاه درخواست می‌شود، یعنی دسترسی به همه دستگاه‌ها به‌طور پیش‌فرض مجاز است، قواعد مجاز خاص برای دستگاه‌های منفرد یا رده‌های دستگاه نادیده گرفته می‌شوند.

برای نمونه، مجموعه قواعد:

lxc.cgroup2.devices.deny = a
lxc.cgroup2.devices.allow = c *:* m
lxc.cgroup2.devices.allow = b *:* m
lxc.cgroup2.devices.allow = c 1:3 rwm

یک برنامه دستگاه‌های فهرست سفید را پیاده‌سازی می‌کند، یعنی هسته دسترسی به همه دستگاه‌هایی را که به‌طور خاص در این فهرست مجاز نشده‌اند، مسدود خواهد کرد. این برنامه خاص مشخص می‌کند که تمام دستگاه‌های نویسه‌ای و بلوکی ممکن است ساخته شوند، اما تنها /dev/null اجازه خوانده‌شدن یا نوشته‌شدن دارد.

اگر در عوض به مجموعه قواعد زیر جابه‌جا شویم:

lxc.cgroup2.devices.allow = a
lxc.cgroup2.devices.deny = c *:* m
lxc.cgroup2.devices.deny = b *:* m
lxc.cgroup2.devices.deny = c 1:3 rwm

آنگاه LXC به هسته دستور می‌دهد تا یک فهرست سیاه پیاده‌سازی کند، یعنی هسته دسترسی به تمام دستگاه‌هایی را که به‌طور خاص در این فهرست رد نشده‌اند، مجاز می‌کند. این برنامه خاص مشخص می‌کند که هیچ دستگاه نویسه‌ای یا بلوکی نباید ساخته شود و /dev/null اجازه خواندن، نوشتن یا ساخته‌شدن را ندارد.

اکنون همان برنامه را در نظر بگیرید، اما به دنبال آن یک «قاعده سراسری» که نوع برنامه دستگاه (فهرست سفید یا فهرست سیاه) را همان‌طور که در بالا توضیح داده شد تعیین می‌کند، آمده باشد:

lxc.cgroup2.devices.allow = a
lxc.cgroup2.devices.deny = c *:* m
lxc.cgroup2.devices.deny = b *:* m
lxc.cgroup2.devices.deny = c 1:3 rwm
lxc.cgroup2.devices.allow = a

خط آخر باعث می‌شود LXC بدون تغییر نوع برنامه دستگاه، فهرست دستگاه‌ها را بازنشانی کند.

اگر در عوض مشخص کنیم:

lxc.cgroup2.devices.allow = a
lxc.cgroup2.devices.deny = c *:* m
lxc.cgroup2.devices.deny = b *:* m
lxc.cgroup2.devices.deny = c 1:3 rwm
lxc.cgroup2.devices.deny = a

آنگاه خط آخر باعث می‌شود LXC فهرست دستگاه‌ها را بازنشانی کرده و از یک برنامه فهرست سفید به یک برنامه فهرست سیاه جابه‌جا شود.

مقدار گروه کنترلی (cgroup) را برای تنظیم در سلسله‌مراتب سنتی cgroup مشخص می‌کند. نام کنترل‌کننده، نام دقیق گروه کنترلی است. نام‌های مجاز و ساختار مقادیر آن‌ها توسط LXC تعیین نمی‌شود، بلکه به ویژگی‌های هسته لینوکسِ در حال اجرا در زمان راه‌اندازی کانتینر بستگی دارد، مانند: lxc.cgroup.cpuset.cpus
مقدار گروه کنترلی را برای تنظیم در سلسله‌مراتب یکپارچه cgroup مشخص می‌کند. نام کنترل‌کننده، نام دقیق گروه کنترلی است. نام‌های مجاز و ساختار مقادیر آن‌ها توسط LXC تعیین نمی‌شود، بلکه به ویژگی‌های هسته لینوکسِ در حال اجرا در زمان راه‌اندازی کانتینر بستگی دارد، مانند: lxc.cgroup2.memory.high
دایرکتوری یا مسیری را که cgroup کانتینر در آن ساخته می‌شود مشخص می‌کند. به عنوان مثال، تنظیم lxc.cgroup.dir = my-cgroup/first برای کانتینری با نام "c1"، گروه کنترلی کانتینر را به عنوان یک زیرگروه از "my-cgroup" ایجاد خواهد کرد. به عنوان مثال، اگر cgroup فعلی کاربر با نام "my-user" در ریشه cgroup کنترل‌کننده cpuset در یک سلسله‌مراتب cgroup v1 قرار داشته باشد، این کار cgroup با مسیر "/sys/fs/cgroup/cpuset/my-user/my-cgroup/first/c1" را برای کانتینر ایجاد می‌کند. هرگونه cgroup ناموجود توسط LXC ایجاد خواهد شد. این موضوع مستلزم آن است که کاربر دسترسی نوشتن روی cgroup فعلی خود داشته باشد.
مشابه lxc.cgroup.dir است، اما باید همراه با lxc.cgroup.dir.monitor استفاده شود و فقط بر مسیر cgroup کانتینر تأثیر می‌گذارد. این گزینه با lxc.cgroup.dir ناسازگار است و نمی‌توانند هم‌زمان استفاده شوند. توجه داشته باشید که مسیر نهایی که کانتینر به آن متصل می‌شود می‌تواند توسط گزینه lxc.cgroup.dir.container.inner بیشتر گسترش یابد.
همتای مربوط به فرایند پایشگر برای lxc.cgroup.dir.container است.
هنگام خاتمه کانتینر، شناسه فرایند (PID) مربوط به فرایند پایشگر به این cgroup متصل می‌شود. این مسیر نباید زیرمسیر هیچ دایرکتوری cgroup پیکربندی‌شده دیگری باشد تا از حذف صحیح سایر مسیرهای cgroup در زمان پایان کار کانتینر اطمینان حاصل شود.
یک زیردایرکتوری اضافی را مشخص می‌کند که فضای‌نام cgroup در آن ایجاد خواهد شد. با این گزینه، محدودیت‌های cgroup بر روی مسیر بیرونی مشخص‌شده در lxc.cgroup.dir.container اعمال می‌شوند که از داخل کانتینر قابل دسترسی نیست؛ این قابلیت اعمال محدودیت‌ها را برای کانتینرهای ممتاز (privileged) به گونه‌ای ممکن می‌سازد که نتوانند آن‌ها را لغو یا بازنویسی کنند. این گزینه فقط در کنار گزینه‌های lxc.cgroup.dir.container و lxc.cgroup.dir.monitor کار می‌کند و در غیر این صورت هیچ اثری ندارد.
این مقدار را روی 1 قرار دهید تا به LXC دستور داده شود هرگز به cgroup ریشه خارج نشود. این قابلیت تبعیت کاربران از محدودیت‌های اعمال‌شده توسط cgroup2 و systemd را آسان می‌کند. به‌طور مشخص، اجرای کانتینرهای LXC را به عنوان سرویس‌های systemd ممکن می‌سازد.

اگر کانتینر به عنوان کاربر root اجرا شود، قابلیت‌ها را می‌توان در آن ساقط (drop) کرد.

قابلیتی که باید در کانتینر ساقط شود را مشخص می‌کند. تعریف چند قابلیت در یک خط واحد با تفکیک توسط فاصله (space) مجاز است. قالب نوشتاری، حروف کوچکِ تعریف قابلیت و بدون پیشوند "CAP_" است، مانند CAP_SYS_MODULE که باید به صورت sys_module مشخص شود. نگاه کنید به capabilities(7). اگر بدون مقدار استفاده شود، lxc تمام قابلیت‌های تعیین‌شده برای ساقط‌سازی تا این نقطه را پاک می‌کند.
قابلیتی که باید در کانتینر نگه داشته شود را مشخص می‌کند. تمام قابلیت‌های دیگر ساقط خواهند شد. در صورت مواجهه با مقدار ویژه "none"، برنامه lxc تمام قابلیت‌های نگه‌داشتنی تعیین‌شده تا این نقطه را پاک خواهد کرد. مقدار "none" به تنهایی می‌تواند برای ساقط کردن تمامی قابلیت‌ها استفاده شود.

یک فضای نام می‌تواند کلون شود (lxc.namespace.clone)، نگه‌داشته شود (lxc.namespace.keep) یا به اشتراک گذاشته شود (lxc.namespace.share.[namespace identifier]).

فضاهای نامی که کانتینر باید با آن‌ها ایجاد شود را مشخص می‌کند. فضاهای نام برای ایجاد به صورت فهرستی جداشده با فاصله مشخص می‌شوند. هر فضای نام باید با یکی از شناسه‌های استاندارد فضای نام که در دایرکتوری /proc/PID/ns دیده می‌شود مطابقت داشته باشد. هنگامی که lxc.namespace.clone به صورت صریح تنظیم نشده باشد، تمام فضاهای نام پشتیبانی‌شده توسط هسته و پیکربندی فعلی استفاده خواهند شد.

برای ایجاد یک فضای نام جدید mount، net و ipc مقدار lxc.namespace.clone=mount net ipc را تنظیم کنید.

فضاهای نامی که کانتینر باید از فرآیند ایجادکننده خود به ارث ببرد را مشخص می‌کند. فضاهای نام برای نگه‌داشتن به صورت فهرستی جداشده با فاصله مشخص می‌شوند. هر فضای نام باید با یکی از شناسه‌های استاندارد فضای نام همان‌طور که در دایرکتوری /proc/PID/ns دیده می‌شود مطابقت داشته باشد. گزینه lxc.namespace.keep یک گزینه لیست انکار (denylist) است، یعنی زمانی مفید است که بخواهید کانتینرها را ملزم به نگه‌داشتن مجموعه خاصی از فضاهای نام کنید.

برای نگه‌داشتن فضاهای نام network، user و ipc مقدار lxc.namespace.keep=user net ipc را تنظیم کنید.

توجه داشته باشید که به اشتراک‌گذاری فضاهای نام pid احتمالاً با بیشتر سیستم‌های init کار نخواهد کرد.

توجه داشته باشید که اگر کانتینر یک فضای نام جدید user درخواست کند و بخواهد فضای نام network را به ارث ببرد، باید فضای نام user را نیز به ارث ببرد.

یک فضای نام را برای به ارث بردن از کانتینر یا فرآیند دیگر مشخص می‌کند. پسوند [namespace identifier] باید با یکی از فضاهای نام موجود در دایرکتوری /proc/PID/ns جایگزین شود.

برای به ارث بردن فضای نام از یک فرآیند دیگر، مقدار lxc.namespace.share.[namespace identifier] را روی PID آن فرآیند تنظیم کنید، مثلاً lxc.namespace.share.net=42.

برای به ارث بردن فضای نام از یک کانتینر دیگر، مقدار lxc.namespace.share.[namespace identifier] را روی نام کانتینر تنظیم کنید، مثلاً lxc.namespace.share.pid=c3.

برای به ارث بردن فضای نام از کانتینری واقع در مسیری متفاوت از مسیر استاندارد liblxc، مقدار lxc.namespace.share.[namespace identifier] را روی مسیر کامل کانتینر تنظیم کنید، مثلاً lxc.namespace.share.user=/opt/c3.

به منظور به ارث بردن فضاهای نام، فراخواننده باید دسترسی و امتیاز کافی بر روی فرآیند یا کانتینر داشته باشد.

توجه داشته باشید که به اشتراک‌گذاری فضاهای نام pid بین کانتینرهای سیستمی احتمالاً با بیشتر سیستم‌های init کار نخواهد کرد.

توجه داشته باشید که اگر دو فرآیند در فضاهای نام user متفاوتی باشند و یک فرآیند بخواهد فضای نام network دیگری را به ارث ببرد، معمولاً نیاز است فضای نام user را نیز به ارث ببرد.

توجه داشته باشید که بدون پیکربندی دقیق و اضافی یک LSM، به اشتراک‌گذاری فضاهای نام user+pid با یک تسک ممکن است به آن تسک اجازه دهد امتیازات خود را به سطح تسک فراخواننده liblxc ارتقا دهد.

یک آفست مثبت یا منفی برای ساعت boottime مشخص کنید. قالب، ساعت (h)، دقیقه (m)، ثانیه (s)، میلی‌ثانیه (ms)، میکروثانیه (us) و نانوثانیه (ns) را می‌پذیرد.
یک آفست مثبت یا منفی برای ساعت monotonic مشخص کنید. قالب، ساعت (h)، دقیقه (m)، ثانیه (s)، میلی‌ثانیه (ms)، میکروثانیه (us) و نانوثانیه (ns) را می‌پذیرد.

محدودیت‌های منابع نرم (soft) و سخت (hard) برای کانتینر قابل تغییر است. کانتینرهای بدون امتیاز فقط می‌توانند آن‌ها را کاهش دهند. منابعی که به طور صریح مشخص نشده باشند به ارث برده خواهند شد.

محدودیت منبع را برای تنظیم مشخص کنید. یک محدودیت به صورت دو مقدار جدا شده با دونقطه مشخص می‌شود که یا عددی هستند یا عبارت 'unlimited'. از یک مقدار تکی می‌توان به عنوان میان‌بر برای تنظیم هر دو حد نرم و سخت روی مقداری یکسان استفاده کرد. نام‌های مجاز، نام‌های منبع "RLIMIT_" با حروف کوچک و بدون پیشوند "RLIMIT_" هستند، مانند RLIMIT_NOFILE که باید به صورت "nofile" مشخص شود. ببینید: setrlimit(2). در صورت استفاده بدون مقدار، lxc محدودیت منبع مشخص‌شده تا این نقطه را پاک خواهد کرد. منبعی که بدون محدودیت پیکربندی‌شده صریح باشد، از فرآیند راه‌انداز کانتینر به ارث برده خواهد شد.

پیکربندی پارامترهای هسته برای کانتینر.

پارامترهای هسته را برای مقداردهی مشخص می‌کند. پارامترهای دردسترس مواردی هستند که زیر /proc/sys/ فهرست شده‌اند. توجه داشته باشید که همه sysctlها دارای فضای نام تفکیک‌شده نیستند. تغییر sysctlهای فاقد فضای نام باعث تغییر تنظیمات در سطح کل سیستم می‌شود. sysctl(8). اگر بدون مقدار استفاده شود، lxc پارامترهای مشخص‌شده تا این نقطه را پاک خواهد کرد.

اگر lxc با پشتیبانی از apparmor کامپایل و نصب شده باشد، و سیستم میزبان apparmor را فعال کرده باشد، پروفایل apparmor که کانتینر باید تحت آن اجرا شود می‌تواند در پیکربندی کانتینر مشخص گردد. مقدار پیش‌فرض lxc-container-default-cgns است اگر هسته میزبان از فضای نام cgroup پشتیبانی کند، در غیر این صورت lxc-container-default خواهد بود.

پروفایل apparmor که کانتینر باید تحت آن اجرا شود را مشخص می‌کند. برای مشخص کردن اینکه کانتینر باید نامحدود (unconfined) باشد، استفاده کنید از 
lxc.apparmor.profile = unconfined

اگر پروفایل apparmor باید بدون تغییر بماند (برای مثال اگر کانتینرهای تو در تو اجرا می‌کنید و از پیش محدود شده‌اید)، استفاده کنید از

lxc.apparmor.profile = unchanged

اگر به LXC دستور می‌دهید تا پروفایل apparmor را تولید کند، استفاده کنید از

lxc.apparmor.profile = generated
پروفایل‌های apparmor مبتنی بر مسیر هستند. بنابراین بسیاری از محدودیت‌های پرونده نیازمند محدودیت‌های سوار کردن (mount) هستند تا در برابر یک مهاجم مصمم مؤثر باشند. با این حال، این محدودیت‌های سوار کردن هنوز در هسته بالادست پیاده‌سازی نشده‌اند. بدون محدودیت‌های سوار کردن، پروفایل‌های apparmor همچنان در برابر آسیب‌های تصادفی محافظت می‌کنند.

اگر این پرچم 0 باشد (پیش‌فرض)، در صورت عدم پشتیبانی هسته از قابلیت‌های سوار کردن apparmor، کانتینر شروع به کار نخواهد کرد تا پس‌رفت ناشی از ارتقای هسته شناسایی شود. برای شروع به کار کانتینر تحت حفاظت نسبی apparmor، این پرچم را روی 1 تنظیم کنید.

اگر روی 1 تنظیم شود، تغییرات زیر را ایجاد می‌کند. هنگامی که پروفایل‌های تولیدشده apparmor استفاده شوند، شامل تغییرات لازم برای اجازه ساخت کانتینر تو‌در‌تو خواهند بود. علاوه بر نقاط اتصال معمول، /dev/.lxc/proc و /dev/.lxc/sys شامل نقاط اتصال procfs و sysfs بدون لایه‌های lxcfs خواهند بود که در صورت استفاده از پروفایل‌های تولیدشده apparmor، مستقیماً قابل خواندن/نوشتن نخواهند بود.
فهرستی از خطوط خام پروفایل AppArmor برای الحاق به پروفایل. تنها هنگام استفاده از پروفایل‌های تولیدشده معتبر است.

اگر lxc با پشتیبانی از SELinux کامپایل و نصب شده باشد و سیستم میزبان دارای SELinux فعال باشد، زمینه SELinux که کانتینر باید تحت آن اجرا شود می‌تواند در پیکربندی کانتینر مشخص گردد. پیش‌فرض unconfined_t است، بدین معنی که lxc تلاشی برای تغییر زمینه‌ها نخواهد کرد. برای یک نمونه سیاست و اطلاعات بیشتر /usr/share/lxc/selinux/lxc.te را ببینید.

زمینه SELinux که کانتینر باید تحت آن اجرا شود یا unconfined_t را مشخص می‌کند. برای نمونه 
lxc.selinux.context = system_u:system_r:lxc_t:s0:c22
زمینه SELinux که دسته‌کلید (keyring) کانتینر باید تحت آن ساخته شود را مشخص می‌کند. به طور پیش‌فرض این مقدار مشابه lxc.selinux.context است، یا زمینه‌ای است که lxc تحت آن اجرا می‌شود اگر lxc.selinux.context تنظیم نشده باشد. 
lxc.selinux.context.keyring = system_u:system_r:lxc_t:s0:c22

امکان دسته کلید لینوکس (Linux Keyring) اساساً روشی برای اجزای مختلف هسته جهت نگهداری یا حافظه‌نهان‌سازی داده‌های امنیتی، کلیدهای احراز هویت، کلیدهای رمزنگاری و سایر داده‌ها در هسته است. به طور پیش‌فرض lxc یک دسته کلید نشست جدید برای برنامه اجرا شده ایجاد خواهد کرد.

غیرفعال کردن ایجاد دسته کلید نشست جدید توسط lxc. برنامه اجرا شده دسته کلید نشست فعلی را به ارث خواهد برد. به طور پیش‌فرض، یا هنگام ارسال مقدار 1، یک دسته کلید جدید ایجاد خواهد شد. 
lxc.keyring.session = 0

یک کانتینر می‌تواند با بارگذاری یک نمایه seccomp هنگام راه‌اندازی، با مجموعه‌ای کاهش‌یافته از فراخوان‌های سیستمی در دسترس اجرا شود. پرونده پیکربندی seccomp باید با شماره نسخه در خط اول، نوع خط‌مشی در خط دوم آغاز شده و به دنبال آن پیکربندی قرار گیرد.

در حال حاضر نسخه‌های 1 و 2 پشتیبانی می‌شوند. در نسخه 1، خط‌مشی یک فهرست مجاز ساده است. بنابراین خط دوم باید شامل "allowlist" باشد و بقیه پرونده شامل یک شماره (عددی) فراخوان سیستمی در هر خط باشد. هر شماره فراخوان سیستمی در فهرست مجاز قرار می‌گیرد، در حالی که هر شماره ثبت‌نشده برای استفاده در کانتینر در فهرست غیرمجاز خواهد بود.

در نسخه 2، خط‌مشی می‌تواند denylist یا allowlist باشد، از کنش‌های پیش‌فرض به ازای هر قاعده و هر خط‌مشی پشتیبانی می‌کند، و از تطبیق فراخوان سیستمی بر اساس معماری از روی نام‌های متنی پشتیبانی می‌نماید.

یک نمونه خط‌مشی denylist، که در آن تمام فراخوان‌های سیستمی به جز mknod مجاز هستند، که صرفاً کاری انجام نداده و مقدار 0 (موفقیت) را برمی‌گرداند، به شکل زیر است:

2
denylist
mknod errno 0
ioctl notify

تعیین "errno" به عنوان کنش باعث می‌شود LXC یک پالایه seccomp ثبت کند که موجب بازگرداندن یک errno مشخص به فراخواننده خواهد شد. مقدار errno را می‌توان پس از واژه کنش "errno" مشخص کرد.

تعیین "notify" به عنوان کنش باعث می‌شود LXC یک شنونده seccomp ثبت کرده و یک توصیف‌گر پرونده شنونده از هسته دریافت کند. هنگامی که یک فراخوان سیستمی ثبت‌شده به عنوان "notify" فراخوانی شود، هسته یک رویداد poll تولید کرده و پیامی را از طریق توصیف‌گر پرونده ارسال می‌کند. فراخواننده می‌تواند این پیام را بخواند و فراخوان‌های سیستمی شامل آرگومان‌های آن را بررسی کند. بر اساس این اطلاعات انتظار می‌رود فراخواننده پیامی ارسال کند که به هسته اطلاع دهد چه کنشی انجام دهد. تا زمانی که آن پیام ارسال نشود، هسته فرایند فراخواننده را مسدود خواهد کرد. قالب پیام‌های خواندنی و ارسالی در خود seccomp مستند شده است.

مشخص کردن پرونده حاوی پیکربندی seccomp برای بارگذاری پیش از شروع کانتینر.
اگر این پرچم روی 1 تنظیم شود، فیلترهای seccomp صرف‌نظر از اینکه نمایه seccomp از پیش بارگذاری شده باشد یا خیر، روی هم انباشته می‌شوند. این ویژگی به کانتینرهای تو در تو امکان می‌دهد نمایه seccomp اختصاصی خود را بارگذاری کنند. تنظیم پیش‌فرض 0 است.
مشخص کردن یک سوکت یونیکس که LXC به آن متصل شده و رویدادهای seccomp را به آن هدایت می‌کند. مسیر باید به شکل unix:/path/to/socket یا unix:@socket باشد. اولی یک سوکت دامنه یونیکس وابسته به مسیر و دومی یک سوکت دامنه یونیکس انتزاعی را مشخص می‌کند.
رشته‌ای اضافی که همراه با درخواست‌های اعلان seccomp پروکسی‌شده ارسال می‌شود.

با فعال بودن PR_SET_NO_NEW_PRIVS، فراخوانی execve() متعهد می‌شود دسترسی‌هایی را که بدون فراخوانی execve() امکان دستیابی به آن‌ها وجود نداشت، اعطا نکند (به عنوان مثال، غیرفعال کردن بیت‌های حالت set-user-ID و set-group-ID و قابلیت‌های پرونده). این بیت پس از تنظیم، دیگر قابل بازنشانی نیست. مقدار این بیت توسط فرزندان ایجاد شده با fork() و clone() به ارث برده شده و در طول execve() حفظ می‌شود. توجه داشته باشید که PR_SET_NO_NEW_PRIVS پس از انتقال کانتینر به نمایه AppArmor یا زمینه SElinux مورد نظر آن اعمال می‌گردد.

مشخص می‌کند که آیا پرچم PR_SET_NO_NEW_PRIVS باید برای کانتینر تنظیم شود یا خیر. مقدار را برای فعال‌سازی روی 1 قرار دهید.

یک کانتینر می‌تواند در یک فضای‌نام کاربری خصوصی با نگاشت‌های شناسه کاربر و گروه راه‌اندازی شود. برای نمونه، می‌توانید userid مقدار 0 در کانتینر را به userid مقدار 200000 روی میزبان نگاشت کنید. کاربر root در کانتینر، درون کانتینر دارای دسترسی ممتاز خواهد بود، اما روی میزبان فاقد دسترسی ممتاز است. معمولاً یک کانتینر سیستمی به بازه‌ای از شناسه‌ها نیاز دارد، بنابراین شما به عنوان نمونه، شناسه‌های کاربر و گروه 0 تا 20,000 در کانتینر را به شناسه‌های 200,000 تا 220,000 نگاشت می‌کنید.

باید چهار مقدار ارائه شود. نخست یک نویسه، یا 'u' یا 'g'، تا مشخص شود شناسه‌های کاربر یا گروه در حال نگاشت هستند. مقدار بعدی اولین userid است آن‌گونه که در فضای‌نام کاربری کانتینر دیده می‌شود. سپس userid آن‌طور که روی میزبان دیده می‌شود. در نهایت، بازه‌ای که تعداد شناسه‌های متوالی را برای نگاشت مشخص می‌کند.

قلاب‌های کانتینر برنامه‌ها یا اسکریپت‌هایی هستند که می‌توانند در زمان‌های مختلف از چرخه حیات یک کانتینر اجرا شوند.

هنگام اجرای یک قلاب کانتینر، اطلاعات اضافی نیز منتقل می‌شود. از آرگومان lxc.hook.version می‌توان برای تعیین اینکه آیا آرگومان‌های زیر به صورت آرگومان‌های خط فرمان یا از طریق متغیرهای محیطی ارسال شوند استفاده کرد. این آرگومان‌ها عبارتند از:

•
نام کانتینر.
•
بخش (همیشه 'lxc').
•
نوع قلاب (یعنی 'clone' یا 'pre-mount').
•
آرگومان‌های اضافی. در مورد قلاب clone، هر آرگومان اضافی ارسال‌شده به عنوان آرگومان‌های بعدی به قلاب داده خواهد شد. در مورد قلاب stop، مسیرهای توصیف‌کننده‌های پرونده برای هر یک از فضاهای نام کانتینر همراه با نوع آن‌ها ارسال می‌شود.

متغیرهای محیطی زیر تنظیم می‌شوند:

•
LXC_CGNS_AWARE: نشانگر آگاهی کانتینر از فضای‌نام cgroup.
•
LXC_CONFIG_FILE: مسیر پرونده پیکربندی کانتینر.
•
LXC_HOOK_TYPE: نوع قلاب (مانند 'clone' ،'mount' و 'pre-mount'). توجه داشته باشید که وجود این متغیر محیطی مشروط به مقدار lxc.hook.version است. اگر مقدار آن 1 باشد، LXC_HOOK_TYPE تنظیم خواهد شد.
•
LXC_HOOK_SECTION: نوع بخش (مانند 'lxc' و 'net'). توجه داشته باشید که وجود این متغیر محیطی مشروط به مقدار lxc.hook.version است. اگر مقدار آن 1 باشد، LXC_HOOK_SECTION تنظیم خواهد شد.
•
LXC_HOOK_VERSION: نسخه قلاب‌ها. این مقدار با مقدار گزینه پیکربندی lxc.hook.version کانتینر یکسان است. اگر روی 0 تنظیم شود از قلاب‌های سبک قدیمی استفاده می‌شود. اگر روی 1 تنظیم شود از قلاب‌های سبک جدید استفاده می‌شود.
•
LXC_LOG_LEVEL: سطح گزارش‌گیری کانتینر.
•
LXC_NAME: نام کانتینر است.
•
LXC_[NAMESPACE IDENTIFIER]_NS: مسیر زیر /proc/PID/fd/ به یک توصیف‌کننده پرونده که به فضای‌نام کانتینر اشاره دارد. برای هر نوع فضای‌نام حفظ‌شده یک متغیر محیطی جداگانه وجود خواهد داشت. این متغیرهای محیطی تنها در صورتی تنظیم می‌شوند که lxc.hook.version روی 1 تنظیم شده باشد.
•
LXC_ROOTFS_MOUNT: مسیر سیستم پرونده ریشه سوارشده.
•
LXC_ROOTFS_PATH: این مدخل lxc.rootfs.path برای کانتینر است. توجه داشته باشید که این به احتمال زیاد مکانی نیست که rootfs سوارشده در آن پیدا شود، برای این منظور از LXC_ROOTFS_MOUNT استفاده کنید.
•
LXC_SRC_NAME: در مورد قلاب clone، این نام کانتینر اصلی است.

خروجی استاندارد از قلاب‌ها در سطح debug ثبت می‌شود. خطای استاندارد ثبت نمی‌شود، اما می‌تواند با تغییر مسیر خطای استاندارد قلاب به خروجی استاندارد، ضبط شود.

برای ارسال آرگومان‌ها به شیوه جدید از طریق متغیرهای محیطی مقدار را روی 1 تنظیم کنید، در غیر این صورت برای ارسال به عنوان آرگومان مقدار را روی 0 قرار دهید. این تنظیم بر تمامی آرگومان‌های قلاب که به طور سنتی به عنوان آرگومان به اسکریپت ارسال می‌شدند تأثیر می‌گذارد. به طور مشخص، این گزینه بر آرگومان‌های نام کانتینر، بخش (مانند 'lxc' یا 'net') و نوع قلاب (مانند 'clone'، 'mount' و 'pre-mount') اثرگذار است. اگر از قلاب‌های شیوه جدید استفاده شود، آرگومان‌ها به صورت متغیرهای محیطی در دسترس خواهند بود. نام کانتینر در LXC_NAME قرار می‌گیرد. (این مقدار مستقل از مقدار استفاده شده برای این گزینه پیکربندی تعیین می‌شود.) بخش در LXC_HOOK_SECTION و نوع قلاب در LXC_HOOK_TYPE تنظیم خواهد شد. این گزینه همچنین بر نحوه ارسال مسیرهای توصیف‌کننده‌های پرونده مرتبط با فضاهای‌نام کانتینر تأثیر می‌گذارد. در صورت تنظیم روی 1، برای هر فضای‌نام یک متغیر محیطی جداگانه به صورت LXC_[NAMESPACE IDENTIFIER]_NS تنظیم خواهد شد. در صورت تنظیم روی 0، مسیرها به عنوان آرگومان به قلاب stop ارسال می‌شوند.
قلابی که پیش از بالا آمدن ttyها، کنسول‌ها یا سوارشدن‌های (mounts) کانتینر، در فضای‌نام میزبان اجرا می‌شود.
قلابی که در فضای‌نام fs کانتینر اما پیش از راه‌اندازی rootfs اجرا می‌شود. این امکان دستکاری rootfs را فراهم می‌کند، به عنوان مثال برای سوار کردن یک سیستم پرونده رمزگذاری‌شده. سوارشدن‌های انجام‌شده در این قلاب روی میزبان بازتاب نخواهند یافت (به جز انتشار سوارشدن‌ها)، بنابراین هنگام خاموش شدن کانتینر به طور خودکار پاکسازی می‌شوند.
قلابی که پس از انجام عملیات سوار کردن، اما پیش از pivot_root در فضای‌نام کانتینر اجرا می‌شود.
قلابی که در صورت lxc.autodev == 1، پس از انجام عملیات سوار کردن و پس از اجرای تمام قلاب‌های mount، اما پیش از pivot_root در فضای‌نام کانتینر اجرا می‌شود. هدف این قلاب کمک به پر کردن دایرکتوری /dev کانتینر هنگام استفاده از گزینه autodev برای کانتینرهای مبتنی بر systemd است. دایرکتوری /dev کانتینر نسبت به متغیر محیطی ${LXC_ROOTFS_MOUNT} که در زمان اجرای قلاب در دسترس است سنجیده می‌شود.
قلابی که پس از راه‌اندازی کانتینر و بلافاصله پیش از اجرای init کانتینر، در فضای‌نام میزبان اجرا می‌شود.
قلابی که بلافاصله پیش از اجرای init کانتینر، در فضای‌نام کانتینر اجرا می‌شود. این گزینه نیاز دارد که برنامه در کانتینر موجود باشد.
قلابی که پس از خاموش شدن کانتینر، همراه با ارجاعاتی به فضاهای‌نام کانتینر در فضای‌نام میزبان اجرا می‌شود. به ازای هر فضای‌نام، یک آرگومان اضافی شامل نوع فضای‌نام و نام پرونده‌ای که می‌تواند برای دریافت توصیف‌گر پرونده به فضای‌نام متناظر استفاده شود، با دو‌نقطه (:) جدا شده و به قلاب ارسال می‌گردد. نوع، همان نامی است که در دایرکتوری /proc/PID/ns نمایش داده می‌شود. به عنوان مثال برای فضای‌نام mount، آرگومان معمولاً به شکل mnt:/proc/PID/fd/12 است.
قلابی که پس از خاموش شدن کانتینر در فضای‌نام میزبان اجرا می‌شود.
قلابی که هنگام کلون شدن کانتینر به یک کانتینر جدید اجرا می‌شود. برای اطلاعات بیشتر lxc-clone(1) را ببینید.
قلابی که هنگام نابود شدن کانتینر اجرا می‌شود.

تعدادی متغیر محیطی در اختیار هوک‌های راه‌اندازی قرار می‌گیرند تا اطلاعات پیکربندی را فراهم کرده و به عملکرد هوک‌ها کمک کنند. همه متغیرها در تمام زمینه‌ها معتبر نیستند. به‌ویژه، تمامی مسیرها نسبت به سیستم میزبان هستند و از این رو، در طول اجرای هوک lxc.hook.start معتبر نخواهند بود.

نام LXC کانتینر. برای ثبت پیام‌ها در محیط‌های لاگ معمول کاربرد دارد. [-n]
مسیر پرونده پیکربندی کانتینر نسبت به میزبان. این متغیر امکان ارجاع به پرونده پیکربندی اصلی و سطح بالای کانتینر را فراهم می‌کند تا اطلاعات پیکربندی اضافی که به روش دیگر در دسترس نیستند بازیابی شوند. [-f]
مسیر خروجی کنسول کانتینر در صورتی که NULL نباشد. [-c] [lxc.console.path]
مسیر خروجی لاگ کنسول کانتینر در صورتی که NULL نباشد. [-L]
محل سوار شدنی (mount) که کانتینر در ابتدا به آن متصل می‌شود. این مقدار مسیر نسبت به میزبان به rootfs کانتینر در حال راه‌اندازی است و مکانی است که تغییرات باید برای آن نمونه اعمال شوند. [lxc.rootfs.mount]
مسیر نسبت به میزبان به ریشه کانتینر که در مکان rootfs.mount سوار شده است. [lxc.rootfs.path]
فقط برای هوک clone. روی نام اصلی کانتینر تنظیم می‌شود.
فقط برای هوک stop. برای خاموش شدن کانتینر روی "stop" یا برای راه‌اندازی مجدد کانتینر روی "reboot" تنظیم می‌شود.
اگر تنظیم نشده باشد، این نسخه از lxc از فضاهای نام cgroup آگاه نیست. اگر تنظیم شده باشد، مقدار آن 1 خواهد بود و lxc از فضاهای نام cgroup آگاه است. توجه کنید این مورد فعال بودن فضاهای نام cgroup در هسته را تضمین نمی‌کند. این متغیر توسط هوک سوار کردن lxcfs استفاده می‌شود.

گزارش‌گیری را می‌توان بر اساس هر کانتینر پیکربندی کرد. به‌طور پیش‌فرض، بسته به نحوه کامپایل بسته lxc، راه‌اندازی کانتینر فقط در سطح ERROR ثبت می‌شود و در پرونده‌ای به نام کانتینر (با پسوند '.log') در مسیر کانتینر یا در /var/log/lxc ذخیره می‌شود.

هم سطح گزارش‌گیری پیش‌فرض و هم پرونده گزارش را می‌توان در پرونده پیکربندی کانتینر مشخص کرد که رفتار پیش‌فرض را لغو می‌کند. توجه داشته باشید که ورودی‌های پرونده پیکربندی نیز می‌توانند توسط گزینه‌های خط فرمان lxc-start لغو شوند.

سطحی که گزارش‌گیری در آن انجام می‌شود. سطح گزارش یک عدد صحیح در بازه 0..8 است که عدد کوچکتر به معنی اشکال‌زدایی با جزئیات بیشتر است. به‌طور مشخص 0 = trace و 1 = debug و 2 = info و 3 = notice و 4 = warn و 5 = error و 6 = critical و 7 = alert و 8 = fatal. در صورت عدم تعیین، مقدار پیش‌فرض سطح 5 (error) است، بنابراین تنها خطاها و بالاتر گزارش می‌شوند.

توجه داشته باشید هنگامی که یک اسکریپت (مانند اسکریپت hook یا اسکریپت بالا یا پایین آوردن رابط شبکه) فراخوانی می‌شود، خروجی استاندارد اسکریپت در سطح 1 (debug) ثبت می‌شود.

پرونده‌ای که اطلاعات گزارش‌گیری باید در آن نوشته شود.
ارسال اطلاعات گزارش‌گیری به syslog. این گزینه از سطح گزارش تعریف‌شده در lxc.log.level پیروی می‌کند. آرگومان باید facility مربوط به syslog باشد؛ مقادیر معتبر عبارتند از: daemon, local0, local1, local2, local3, local4, local5, local5, local6, local7.

گزینه‌های شروع خودکار از مشخص کردن اینکه کدام کانتینرها باید به صورت خودکار و با چه ترتیبی شروع شوند پشتیبانی می‌کنند. این گزینه‌ها می‌توانند مستقیماً توسط ابزارهای LXC یا ابزارهای خارجی ارائه‌شده توسط توزیع‌ها استفاده شوند.

تعیین می‌کند که آیا کانتینر باید به صورت خودکار شروع شود یا خیر. مقادیر معتبر 0 (خاموش) و 1 (روشن) هستند.
مدت زمان انتظار (به ثانیه) پس از شروع کانتینر، پیش از شروع کانتینر بعدی.
یک عدد صحیح برای مرتب‌سازی کانتینرها هنگام شروع خودکار مجموعه‌ای از کانتینرها به صورت همزمان. مقدار کمتر به معنای شروع زودتر است.
اگر صفر نباشد، فضای نام سوار کردن (mount namespace) پیش از مقداردهی اولیه کانتینر (قبل از اجرای قلاب‌های pre-start) از میزبان جدا (unshare) می‌شود. این مورد نیازمند قابلیت CAP_SYS_ADMIN هنگام راه‌اندازی است. پیش‌فرض 0 است.
تنظیم سیگنالی که هنگام خروج lxc monitor به فرایند init کانتینر ارسال می‌شود. به صورت پیش‌فرض روی SIGKILL تنظیم شده است که باعث می‌شود با متوقف شدن فرایند lxc monitor، تمامی فرایندهای کانتینر کشته شوند. برای اطمینان از زنده ماندن کانتینرها حتی در صورت متوقف شدن lxc monitor، این مقدار را 0 بگذارید.
یک کلید چندمقداری (قابل استفاده به دفعات) برای قرار دادن کانتینر در یک گروه کانتینری. این گروه‌ها می‌توانند (در کنار کاربردهای دیگر) برای شروع دسته‌ای از کانتینرهای مرتبط استفاده شوند.

هر کانتینر می‌تواند عضوی از هر تعداد گروه یا بدون هیچ گروهی باشد. دو گروه خاص هستند: یکی گروه NULL، یعنی کانتینر متعلق به هیچ گروهی نیست؛ و دیگری گروه "onboot".

هنگامی که سامانه با فعال بودن سرویس LXC بوت می‌شود، نخست تلاش می‌کند هر کانتینری با مقدار lxc.start.auto == 1 را که عضو گروه "onboot" است بوت کند. راه‌اندازی به ترتیب lxc.start.order انجام خواهد شد. اگر مقدار lxc.start.delay مشخص شده باشد، پیش از تلاش برای راه‌اندازی کانتینر بعدی، این تأخیر رعایت می‌شود تا به کانتینر جاری زمان برای آغاز مقداردهی اولیه داده شود و از بارگذاری بیش از حد روی سامانه میزبان جلوگیری گردد. پس از راه‌اندازی اعضای گروه "onboot"، سامانه LXC شروع به بوت کانتینرهای با lxc.start.auto == 1 می‌کند که عضو هیچ گروهی نیستند (گروه NULL) و مشابه گروه onboot عمل خواهد کرد.

اگر می‌خواهید متغیرهای محیطی را به کانتینر ارسال کنید (یعنی متغیرهای محیطی که در دسترس init و تمام فرزندان آن خواهند بود)، می‌توانید از پارامترهای lxc.environment برای این کار استفاده کنید. مراقب باشید هیچ دادهٔ حساسی را ارسال نکنید؛ هر فرآیندی در کانتینر که محیط آن پاک‌سازی نشده باشد به این متغیرها دسترسی خواهد داشت، و متغیرهای محیطی همواره از طریق /proc/PID/environ در دسترس هستند.

زیرکلیدهایی برای محدود کردن دامنهٔ متغیرهای محیطی در دسترس هستند: lxc.environment.runtime تنها برای فرآیند init کانتینر (و تمام فرزندان آن) اعمال می‌شود، و lxc.environment.hooks تنها برای قلاب‌ها اعمال می‌گردد.

این پارامترهای پیکربندی را می‌توان چندین بار مشخص کرد؛ یک بار برای هر متغیر محیطی که می‌خواهید پیکربندی کنید.

متغیرهای محیطی که هم به فرآیند init کانتینر و هم به قلاب‌ها اعمال می‌شوند. مثال: 
lxc.environment = APP_ENV=production
lxc.environment = SYSLOG_SERVER=192.0.2.42

به ارث بردن متغیرهای محیطی میزبان با تعیین نام متغیر بدون علامت "=" امکان‌پذیر است. برای مثال:

lxc.environment = PATH
متغیرهای محیطی که تنها برای پردازه init کانتینر اعمال می‌شوند.
متغیرهای محیطی که تنها برای قلاب‌ها (hooks) اعمال می‌شوند.

علاوه بر چند مثال ارائه‌شده در زیر، نمونه‌های دیگری از پرونده‌های پیکربندی در مسیر /usr/share/doc/lxc/examples موجود است.

این پیکربندی یک کانتینر را جهت استفاده از یک جفت‌دستگاه veth تنظیم می‌کند که یک سر آن به پل br0 (که از پیش توسط مدیر روی سیستم پیکربندی شده) متصل است. نام دستگاه شبکه مجازی قابل مشاهده در کانتینر به eth0 تغییر می‌یابد.

lxc.uts.name = myhostname
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.name = eth0
lxc.net.0.hwaddr = 4a:49:43:49:79:bf
lxc.net.0.ipv4.address = 10.2.3.5/24 10.2.3.255
lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597

این پیکربندی هر دو شناسهٔ کاربر و گروه را در محدودهٔ 0-9999 درون کانتینر، به شناسه‌های 100000-109999 روی میزبان نگاشت می‌کند.

lxc.idmap = u 0 100000 10000
lxc.idmap = g 0 100000 10000

این پیکربندی چندین گروه کنترل را برای برنامه برپا می‌کند؛ cpuset.cpus استفاده از پردازنده‌های مشخص‌شده را محدود می‌کند، cpus.share به گروه کنترل اولویت می‌دهد و devices.allow دستگاه‌های مشخص‌شده را قابل استفاده می‌سازد.

lxc.cgroup.cpuset.cpus = 0,1
lxc.cgroup.cpu.shares = 1234
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = b 8:0 rw

این مثال یک پیکربندی پیچیده را نشان می‌دهد که یک پشتهٔ شبکهٔ پیچیده ایجاد کرده، از گروه‌های کنترل استفاده می‌کند، نام میزبان جدیدی تنظیم می‌نماید، برخی مسیرها را سوار کرده و سیستم‌پروندهٔ ریشه را تغییر می‌دهد.

lxc.uts.name = complex
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.hwaddr = 4a:49:43:49:79:bf
lxc.net.0.ipv4.address = 10.2.3.5/24 10.2.3.255
lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597
lxc.net.0.ipv6.address = 2003:db8:1:0:214:5432:feab:3588
lxc.net.1.type = macvlan
lxc.net.1.flags = up
lxc.net.1.link = eth0
lxc.net.1.hwaddr = 4a:49:43:49:79:bd
lxc.net.1.ipv4.address = 10.2.3.4/24
lxc.net.1.ipv4.address = 192.168.10.125/24
lxc.net.1.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596
lxc.net.2.type = phys
lxc.net.2.flags = up
lxc.net.2.link = random0
lxc.net.2.hwaddr = 4a:49:43:49:79:ff
lxc.net.2.ipv4.address = 10.2.3.6/24
lxc.net.2.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3297
lxc.cgroup.cpuset.cpus = 0,1
lxc.cgroup.cpu.shares = 1234
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = b 8:0 rw
lxc.mount.fstab = /etc/fstab.complex
lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0
lxc.rootfs.path = dir:/mnt/rootfs.complex
lxc.rootfs.options = idmap=container
lxc.cap.drop = sys_module mknod setuid net_raw
lxc.cap.drop = mac_override

chroot(1), pivot_root(8), fstab(5), capabilities(7)

lxc(7), lxc-create(1), lxc-copy(1), lxc-destroy(1), lxc-start(1), lxc-stop(1), lxc-execute(1), lxc-console(1), lxc-monitor(1), lxc-wait(1), lxc-cgroup(1), lxc-ls(1), lxc-info(1), lxc-freeze(1), lxc-unfreeze(1), lxc-attach(1), lxc.conf(5)

2026-08-01