| View previous topic :: View next topic |
| Author |
Message |
depontius
Veteran
Joined: 05 May 2004
Posts: 1925
|
 Posted: Wed Nov 02, 2011 1:02 pm Post subject: Getting started with lxc - with a slight twist |
 |
|
Briefly - I'd like my Thinkpad 510 to run Gentoo native, and use lxc to run multiple RedHat installs under that.
Job requirements pretty much force using RedHat. There's a lot of binary-only software built around it, and some of that software has platform checks looking specifically for it. What's worse, some of that software is specifically looking for RedHat 5.x, and some other software is available in much better versions - for RedHat 6.x. Plus this is all running on a ThinkPad 510 that is better supported on newer platforms.
Right now the system is many-boot. I'm normally running RedHat 6.1 and have tricked most of the necessary software into running there. For the remaining packages I ssh into another machine. I have a Gentoo boot set up which I don't actually boot, but run in a chroot from RedHat. I also have a bootable Fedora Core 14 which has failed to update for some months, and a RedHat 5.2 install which was copied out of a virtual container and hasn't been updated for some months because the update is really an upgrade, which won't work in a chroot. These latter 2 images can be considered "withered". I consider the RedHat 6.1 and Gentoo images to be currently viable.
I find RedHat a bit painful, because it's binary-only and because it's 2.6.32 with so much stuff backported that it scares me a little. I'd really rather just run a modern system.
At the same time, our networking support around here is a bit draconian. "Endpoints" are registered and virtualization is generally routed. This is really the issue that's getting me, here. For lxc the "getting started" documentation is all about bridging, which means that my virtual network in the container is exposed to the company network, which by policy doesn't really like it. I get the impression that lxc supports more forms of networking, but the documentation I've found so far is easy for bridging and either missing or too complex for anything else. There isn't much documentation in the middle.
I'd like to wind up with a Gentoo boot and 2 RedHat guests - a RedHat 6.2 guest for more modern stuff, and a RedHat 5.6/5.7 guest for the stuff that requires the older platform. Plus I'd run what I can native, on Gentoo. I'd want to run X on Gentoo and share the one display with the guests. I'd want one network interface exposed to the corporate network, and prefer to route on RFC1918 networks into the containers.
I think I can see how to run lxc against a bootable install instead of a container, though I'm not sure about how to share filesystems with "outside". The networking is the part really baffling me. Any advice or better documentation pointers would be appreciated.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
 |
new_item
n00b
Joined: 10 Jun 2011
Posts: 13
Location: Poland
|
| Posted: Mon Nov 07, 2011 2:00 pm Post subject: Re: Getting started with lxc - with a slight twist |
|
|
| depontius wrote: |
(...) For lxc the "getting started" documentation is all about bridging, which means that my virtual network in the container is exposed to the company network, which by policy doesn't really like it. I get the impression that lxc supports more forms of networking, but the documentation I've found so far is easy for bridging and either missing or too complex for anything else. There isn't much documentation in the middle.
|
How to use bridging and NAT at the same time with lxc is described here:
- http://www.vislab.uq.edu.au/howto/lxc/lxcnetwork.html
I think that LXC for production enviroment is not the best choice. If something goes wrong with one of the OS's problem solving can take more than you expect.
I think VirtualBOX will be better solution. There is a lot of people using it, so troubleshooting should take less time. Performance gap is not so big (about 25% in comparison with bare metal) and network managment in VBOX is very easy. |
|
| Back to top |
|
|
depontius
Veteran
Joined: 05 May 2004
Posts: 1925
|
| Posted: Mon Nov 07, 2011 3:28 pm Post subject: |
|
|
Thanks for the reference - I think it tells me how to do what I want - in this case, simple NAT.
| Code: | /sbin/brctl addbr br0
/sbin/brctl setfd br0 0
/sbin/ifconfig br0 192.168.100.1 netmask 255.255.255.0 promisc up
/usr/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE |
I've never really done any bridging at all, so the commands are completely unfamiliar to me. But it looks to me as if I have to set up the br0 device, simply to have something that talks between the host and container. Then I'm guessing that I have to do something inside the container to set its br0 device to someplace on the 192.168.100.* network, obviously other than 192.168.100.1. Either that, or since I'm already running dnsmasq, I could enable the dhcp server onto the br0 network. That way the container could always be running dhcp. If it were truly being booted, it would get a real IP from the real dhcp server. If it were being booted as a container, it would get a local IP from dnsmasq running in the real boot.
Our "official virtualization" around here is through kvm, so if I were to want to do true virtualization I'd probably go that way. I'm really hoping to go "fake virtualization" with lxc because it's not just the CPU penalty, but the fact that true virtual containers seem to tie up memory and other resources, as well. As mentioned, I'm wanting to do this for compatibility reasons, not security or debug. By the way, even a "mere 25%" slowdown sounds objectionable to me, when my typical jobs run between 10 minutes and 3 hours. (Different types of jobs, but I run many different types.)
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 6827
|
| Posted: Wed Nov 09, 2011 1:48 am Post subject: |
|
|
The code you posted is for bridging, but you say you want NAT.
There are three major ways[1] to do networking with LXC. You can bridge the guest with the host, which should look to the outside world much the way a bridge of a full KVM/VirtualBox/VMware guest would look. You can NAT the guest through the host, which again looks to the outside world like you NAT'd a full guest. Finally, you can do nothing and allow processes in the LXC containers to have full use of the host network stack. This is the default if you do not specify any network behavior. It gets you up and running very quickly, but it is more trouble to run the same service both on the host and the guest, since they will be competing for the same network interfaces. If you only want guest network access so that you can run client programs in it, this is a good choice. If you still want/need to run the guests with a private network stack, post back and I can walk you through how to set it up.
For sharing filesystems, could you elaborate on your problem? LXC can be thought of as an enhanced chroot mechanism, though it has some quirks. For example, guests unshare their mount namespace on startup, so the host cannot make new filesystems visible into the guest later.[2][3] Aside from those quirks, you can use the LXC fstab to arrange an arbitrarily complex filesystem in which the guest processes run.
[1] I am intentionally ignoring the configurations that are not relevant to the OP's problem, such as macvlan and empty.
[2] You can get around some of this using the shared subtree support, but that requires you to anticipate your mount requirements before the guest starts.
[3] You can get around this even more elegantly using setns with the mount namespace, but that is not present in mainline kernels yet. The LXC developers carry some patches to add it, if you are willing to run a patched kernel. |
|
| Back to top |
|
|
depontius
Veteran
Joined: 05 May 2004
Posts: 1925
|
| Posted: Wed Nov 09, 2011 2:15 pm Post subject: |
|
|
The "needs of the job" pretty much require running RedHat Enterprise, but it really isn't really that simple. Let me see if I can simplify/de-uglify this...
Short version...
I want to boot my system to Gentoo, but have a lot of applications that need RedHat 6.x or RedHat 5.x, quite specifically. So I want to run a pair of chroots/containers, one with each, and run specific applications in the specific environment where they need to be run. We use afs here for our persistent data, and I'd like to share the "/afs" mount point across all images. We also by convention use a volume mounted at "/data" for temporary runtime data, and I'd also like to share that.
Long version...
I'm running Linux on a Lenovo ThinkPad W510, essentially using it as a workstation. (Please don't ask why, at least not here, us PM if you really want to know.)
The W510 is newer than RedHat 5.x, though there has been a lot of back-porting, so maybe the latest RedHat 5.x will run on it, I don't know. I do know that RedHat 6.x runs quite well on it.
I'm in the silicon CAD business. By hook or by crook, most silicon CAD software around here needs to run on RedHat 5.x, though some of it tolerates RedHat 6.x fairly well. I spend a fair amount of time and effort bypassing or faking out "platform checks". In fact I've had more trouble with platform checks than I have with the software. There's one piece of essential software that I know of that just won't run properly without RedHat 5.x.
We also have "office applications", and those just plain want to run on RedHat 6.x, and either won't on RedHat 5.x or at least latest'n'greatest versions don't.
So I'm in a situation where I want/need both RedHat 6.x and RedHat 5.x co-running, which sounds like some form of virtualization would be called for. In fact the company provides RedHat 5.x virtualization under RedHat 6.x, but it's only minimally set up, has a lot (excessive, IMHO) of overhead, etc, etc. I'm doing this for security, and in fact have done some of it by chrooting, but that can be hard to do a "distribution upgrade". As mentioned before, I'm in the silicon CAD business. Even though I have 8G of ram installed on my laptop, believe it or not that's a bit shy for the work I do. I can't afford "heavyweight" virtualization - I need something lighter.
At the same time, I prefer Gentoo, and prefer staying a bit closer to the leading edge. I'm not particularly comfortable with RedHat's "extreme back-porting" practices, where I'm technically now running a 2.6.32-something kernel, but I know for a fact that at least some 3.x features have been back-ported into it. I'd really rather be booting fully-updated Gentoo, and run both RedHat 6.x and RedHat 5.x under that, in some sort of containers. I see lxc as being better than a simple chroot, hence this thread.
As mentioned in "short version", we're heavily invested in afs around here. Full virtualization would also mean running 3 afs clients, 3 afs caches, etc. I'd rather run one afs client in the native boot, and share that with the chroots/containers. We're also heavily invested in a "/data" mount point of local disk, and I'd like to share that. I'm not so certain about "/home", because that might get me into version issues, where the different environments might be running different versions of the same software, and there would be a tug-of-war fought in the configuration files.
I'm not sure what my needs are for the networking. I do know that we have "endpoint registration" and port management on our routers around here, and bridging could well wreak havoc with that. So I'd rather keep just the native MAC visible, and either run NAT to the chroots/containers, or allow visibility of the native interface. In the longer run, it might be neat to run the container network through some sort of tunnels to a fixed machine. That way I could quiesce my containers, suspend my laptop, go to a conference room, and bring things all back up. At the conference room I'd be on another subnet, but that would only matter to the native environment. Assuming it took less than 15 minutes or so between quiesce and resume, all of my connections in the containers would survive intact. That's because the endpoints of the connections would be defined at the tunnel endpoints. It IP inside a NATed/tunneled container wouldn't have changed, and the endpoint at the far end of the tunnel wouldn't have changed either. Only the tunnel itself would have changed, but that wouldn't be visible inside the containers. I could suspend/resume networked applications across a network change... But that's for later.
Does this answer the question better?
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 6827
|
| Posted: Wed Nov 09, 2011 11:05 pm Post subject: |
|
|
Wow.  I only needed a little bit more information to help you, but I do appreciate the brain dump that you provided instead.
Sharing simple filesystems (or portions thereof) from host to LXC guest is easy. Things could get complicated if you have an automounter involved, but if AFS acts the same as non-automounted NFS, then I would not expect problems there. Sharing the local storage is much easier.
You did not say that you want to run servers, so for now I will assume that sharing the host network stack with the guest is acceptable. We can change that later if it becomes a problem, or when you decide to implement the tunnel scheme you described near the end. The below may not be exactly right on the first try, but it should get you close. Make directory /etc/lxc/rh5. Create files as follows: | /etc/lxc/rh5/config: | lxc.mount = /etc/lxc/rh5/fstab
lxc.rootfs = /usr/lib/lxc/rootfs
# Restrict access to device files. First, deny everything. Then, grant
# access to three character devices:
# 1:3 /dev/null
# 1:8 /dev/random
# 1:9 /dev/urandom
# Add more devices here if needed. Find the major/minor numbers via
# ls -l. If it gets to be too much trouble, just comment all the
# lxc.cgroup.devices.* entries for now.
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = c 1:8 rw
lxc.cgroup.devices.allow = c 1:9 rw |
| /etc/lxc/rh5/fstab: | # All the bound filesystems will be read-only in the guest. Change the
# "ro," if you do not want that.
/mnt/rh5-root /usr/lib/lxc/rootfs none bind,ro,nodev 0 0
# If your RH5 has separate usr/var, use these next two lines.
# Otherwise, delete them.
/mnt/rh5-usr usr none bind,ro,nodev 0 0
/mnt/rh5-var var none bind,ro,nodev,noexec 0 0
/dev dev none bind,rw,noexec 0 0
/dev/pts dev/pts none bind,rw,noexec 0 0
# Give the guest a private /dev/shm.
tmpfs dev/shm tmpfs rw,noexec,nodev 0 0
/afs afs none bind,rw,nodev,noexec 0 0
/data data none bind,rw,nodev,noexec 0 0
/bin bin none bind,ro,nodev 0 0
/lib64 lib64 none bind,ro,nodev 0 0
/usr/lib64 usr/lib64 none bind,ro,nodev 0 0 |
Then, start your container with lxc-execute --name rh5 --rcfile /etc/lxc/rh5/config -- /bin/bash -l. Your first order of business is to /bin/umount -l /usr/lib64 /lib64 /bin && exec /bin/bash -l. You can put that in a one line script or try to pass it via the lxc-init command line. This particular bit of silliness is because the container runs lxc-init from the guest filesystem, not the host filesystem. Therefore, you need a compatible lxc-init in the right place or the guest will not start. Bind mounting the right parts of the host into the guest will achieve this, though it is a bit ugly. |
|
| Back to top |
|
|
depontius
Veteran
Joined: 05 May 2004
Posts: 1925
|
| Posted: Thu Nov 10, 2011 3:07 pm Post subject: |
|
|
Your example is probably a bit more complex than I actually need, but it's getting the idea across to me. I still have a few points and a few questions for clarification...
First to make a minor point... my various OS installations are very simple - just a root. Stuff like /usr, /var, and /home are on that same partition. As previously mentioned, I'm not sharing /home for fear of version conflicts between distributions.
Next point/question... I have a partition for the afs cache, and a partition for nfs cache/cachefilesd. I don't believe I need to share these partitions, because to userspace they don't really exist. I just need to share any afs/nfs mount points, correct? At the moment, my /afs is hard-mounted, but the nfs is unfortunately auto-mounted, though the mount points are fixed. I'm not so concerned about the nfs at the moment - it can wait.
Next question... Since you've said nothing in the suggested config files about networking, I presume that the containers are simply sharing the host networking?
Next question... In your suggested fstab I see that the mountpoint targets are all relative paths, not absolute. I presume that's because they're all relative to "lxc.rootfs"?
You gave examples with rh5 in the container, though at the moment my rh5 installation has withered, and will need to be redone. That's not significant for the moment. I need to begin with Gentoo and RH6. I've installed lxc for both, so I should be able to do this symmetrically. At the moment I'm booted to RH6, so it looks as if I want to adapt your advice for Gentoo, and try Gentoo in an lxc container first. Then I can make the configurations for the other side, boot Gentoo, and try RH6 in an lxc container. Presuming this all works, I reinstall RH5.x and get that working in an lxc container as well.
Thanks for your assistance, I'll keep this thread updated on my progress.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 6827
|
| Posted: Thu Nov 10, 2011 10:08 pm Post subject: |
|
|
| depontius wrote: | First to make a minor point... my various OS installations are very simple - just a root. Stuff like /usr, /var, and /home are on that same partition. As previously mentioned, I'm not sharing /home for fear of version conflicts between distributions.
|
That makes things a little simpler. You can still use bind mounts to achieve ro/nosuid/noexec as needed in the container.
| depontius wrote: | Next point/question... I have a partition for the afs cache, and a partition for nfs cache/cachefilesd. I don't believe I need to share these partitions, because to userspace they don't really exist. I just need to share any afs/nfs mount points, correct? At the moment, my /afs is hard-mounted, but the nfs is unfortunately auto-mounted, though the mount points are fixed. I'm not so concerned about the nfs at the moment - it can wait.
|
Right.
| depontius wrote: | | Next question... Since you've said nothing in the suggested config files about networking, I presume that the containers are simply sharing the host networking? |
Yes.
| depontius wrote: | | Next question... In your suggested fstab I see that the mountpoint targets are all relative paths, not absolute. I presume that's because they're all relative to "lxc.rootfs"? |
Yes.
| depontius wrote: | | At the moment I'm booted to RH6, so it looks as if I want to adapt your advice for Gentoo, and try Gentoo in an lxc container first. |
Aside from adjusting the names, everything should be the same whether you want RH outside and Gentoo inside or Gentoo outside and RH inside. |
|
| Back to top |
|
|
depontius
Veteran
Joined: 05 May 2004
Posts: 1925
|
| Posted: Thu Nov 17, 2011 5:06 pm Post subject: |
|
|
Just so you know, I appreciate all of your help, and hope to get to this shortly. Real Work has ramped up a bit lately, and my experiment time has dwindled. Plus the fact that I plan on this crashing my system at least once, and I can't let stuff running in the background get interrupted.
I'll get there, and I'll give feedback.
Thanks again.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
depontius
Veteran
Joined: 05 May 2004
Posts: 1925
|
| Posted: Tue Nov 22, 2011 4:38 pm Post subject: |
|
|
First and second tries have failed:
| Code: | [root@localhost ~]# lxc-execute --name gentoo --rcfile /usr/local/etc/lxc/gentoo/config -- /bin/bash -I
lxc-execute: cgroup is not mounted
lxc-execute: failed to spawn '/usr/libexec/lxc-init'
lxc-execute: cgroup is not mounted |
I believe I do have cgroup mounted. There is content in /cgroup, and I'm running a thing called "speedy200" that is supposed to be a shell-script-based equivalent to the autosched kernel feature. (The system is currently running RedHat 6.2, with it's way-patched 2.6.32 kernel.) Running "mount" doesn't show /cgroup mounted, nor is there an entry for it in /etc/fstab
I also see "cgconfig" and "cgred" actions that have something to do with cgroups, though "speedy200" doesn't list either as a requirement. It's almost making me think that I don't really have "speedy200" working, because it's pre-reqs aren't both running. But /cgroup has content - directories and sensible looking files in those directories.
I even added a cgroup bind-mount to fstab, with no change to symptoms. (Commented back out_
Just tried making sure "cgred" was running, then tried lxc-execute again, same symptoms.
Even though "mount" doesn't show /cgroup, I find this in /proc.mounts:
| Code: | cgroup /cgroup/cpuset cgroup rw,relatime,cpuset 0 0
cgroup /cgroup/cpu cgroup rw,relatime,cpu,release_agent=/usr/sbin/cgroup_clean 0 0
cgroup /cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0
cgroup /cgroup/memory cgroup rw,relatime,memory 0 0
cgroup /cgroup/devices cgroup rw,relatime,devices 0 0
cgroup /cgroup/freezer cgroup rw,relatime,freezer 0 0
cgroup /cgroup/net_cls cgroup rw,relatime,net_cls 0 0
cgroup /cgroup/blkio cgroup rw,relatime,blkio 0 0 |
and my lxc configuration:
| Code: | [root@localhost ~]# cat /usr/local/etc/lxc/gentoo/config
lxc.mount = /etc/lxc/gentoo/fstab
lxc.rootfs = /var/run/lxc/gentoo
# Restrict access to device files. First, deny everything. Then, grant
# access to three character devices:
# 1:3 /dev/null
# 1:8 /dev/random
# 1:9 /dev/urandom
# Add more devices here if needed. Find the major/minor numbers via
# ls -l. If it gets to be too much trouble, just comment all the
# lxc.cgroup.devices.* entries for now.
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = c 1:8 rw
lxc.cgroup.devices.allow = c 1:9 r
[root@localhost ~]# cat /usr/local/etc/lxc/gentoo/fstab
# All the bound filesystems will be read-only in the guest. Change the
# "ro," if you do not want that.
/mnt/gentoo /var/run/lxc/gentoo none bind,rw,nodev 0 0
# If your RH5 has separate usr/var, use these next two lines.
# Otherwise, delete them.
#/mnt/rh5-usr usr none bind,ro,nodev 0 0
#/mnt/rh5-var var none bind,ro,nodev,noexec 0 0
/dev dev none bind,rw,noexec 0 0
/dev/pts dev/pts none bind,rw,noexec 0 0
/cgroup cgroup non bind,rw 0 0
# Give the guest a private /dev/shm.
tmpfs dev/shm tmpfs rw,noexec,nodev 0 0
/afs afs none bind,rw,nodev,noexec 0 0
/data data none bind,rw,nodev,noexec 0 0
/bin bin none bind,ro,nodev 0 0
/lib64 lib64 none bind,ro,nodev 0 0
/usr/lib64 usr/lib64 none bind,ro,nodev 0 |
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 6827
|
| Posted: Sun Dec 04, 2011 12:28 am Post subject: |
|
|
| depontius wrote: | | Code: | [root@localhost ~]# cat /usr/local/etc/lxc/gentoo/config
lxc.mount = /etc/lxc/gentoo/fstab
[root@localhost ~]# cat /usr/local/etc/lxc/gentoo/fstab
/usr/lib64 usr/lib64 none bind,ro,nodev 0 |
|
I see one possible problem and one definite problem. The possible problem is that the path to fstab specified in your config is not the same as the path you showed for the fstab. The definite problem is that your LXC has a different idea of where to put lxc-init, relative to the LXC that I used as a reference above. For me, with =app-emulation/lxc-0.7.5-r3, lxc-init is installed as /usr/lib/lxc/lxc-init. However, your LXC seems to expect it at /usr/libexec/lxc-init. You will need to bind in /usr/libexec to usr/libexec, similar to what is already done for /usr/lib64. You will also need to add another umount to drop the usr/libexec from the guest before you begin running guest code. |
|
| Back to top |
|
|
depontius
Veteran
Joined: 05 May 2004
Posts: 1925
|
| Posted: Mon Dec 05, 2011 5:03 pm Post subject: |
|
|
The first error you pointed out was a simple typo. Oops, fixed. I also added the suggested bind-mount for /usr/libexec. Still no-go:
| Code: | [root@localhost ~]# lxc-execute --name rh5 --rcfile /usr/local/etc/lxc/gentoo/config -- /bin/bash -l
lxc-execute: cgroup is not mounted
lxc-execute: failed to spawn '/usr/libexec/lxc-init'
lxc-execute: cgroup is not mounted |
Here is my current config:
| Code: | lxc.mount = /usr/local/etc/lxc/gentoo/fstab
lxc.rootfs = /var/run/lxc/gentoo
# Restrict access to device files. First, deny everything. Then, grant
# access to three character devices:
# 1:3 /dev/null
# 1:8 /dev/random
# 1:9 /dev/urandom
# Add more devices here if needed. Find the major/minor numbers via
# ls -l. If it gets to be too much trouble, just comment all the
# lxc.cgroup.devices.* entries for now.
#lxc.cgroup.devices.deny = a
#lxc.cgroup.devices.allow = c 1:3 rw
#lxc.cgroup.devices.allow = c 1:8 rw
#lxc.cgroup.devices.allow = c 1:9 r |
And my current fstab:
| Code: | # All the bound filesystems will be read-only in the guest. Change the
# "ro," if you do not want that.
/mnt/gentoo /var/run/lxc/gentoo none bind,rw,nodev 0 0
# If your RH5 has separate usr/var, use these next two lines.
# Otherwise, delete them.
#/mnt/rh5-usr usr none bind,ro,nodev 0 0
#/mnt/rh5-var var none bind,ro,nodev,noexec 0 0
/dev dev none bind,rw,noexec 0 0
/dev/pts dev/pts none bind,rw,noexec 0 0
#/cgroup cgroup non bind,rw 0 0
# Give the guest a private /dev/shm.
tmpfs dev/shm tmpfs rw,noexec,nodev 0 0
/afs afs none bind,rw,nodev,noexec 0 0
/data data none bind,rw,nodev,noexec 0 0
/bin bin none bind,ro,nodev 0 0
/lib64 lib64 none bind,ro,nodev 0 0
/usr/lib64 usr/lib64 none bind,ro,nodev 0
/usr/libexec usr/libexec none bind,ro,nodev 0 |
Incidentally, I'm currently trying to use RedHat 6.2 as a host for Gentoo. Ultimately I'd like to reverse that, but I'm starting here because work requires RH6.2.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 6827
|
| Posted: Tue Dec 06, 2011 4:01 am Post subject: |
|
|
| The error message says that cgroup is not mounted. Do you have the cgroup filesystem mounted on the host? |
|
| Back to top |
|
|
depontius
Veteran
Joined: 05 May 2004
Posts: 1925
|
| Posted: Tue Dec 06, 2011 1:25 pm Post subject: |
|
|
Yes, I believe I stated that after my first experiment. What's odd is the way it shows up:
| Code: | [root@localhost ~]# ls -l /cgroup/
total 0
drwxr-xr-x 2 root root 0 Dec 5 08:55 blkio
drwxr-xr-x 3 root root 0 Dec 5 08:55 cpu
drwxr-xr-x 2 root root 0 Dec 5 08:55 cpuacct
drwxr-xr-x 2 root root 0 Dec 5 08:55 cpuset
drwxr-xr-x 2 root root 0 Dec 5 08:55 devices
drwxr-xr-x 2 root root 0 Dec 5 08:55 freezer
drwxr-xr-x 2 root root 0 Dec 5 08:55 memory
drwxr-xr-x 2 root root 0 Dec 5 08:55 net_cls
[root@localhost ~]# mount
/dev/sda10 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda2 on /boot type ext3 (rw)
/dev/sda6 on /var/cache/openafs type ext2 (rw,noatime)
/dev/sda7 on /var/fscache type ext4 (rw,noatime,user_xattr)
/dev/sda13 on /data type ext4 (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
AFS on /afs type afs (rw)
gvfs-fuse-daemon on /home/theUser/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=theUser)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/sda9 on /mnt/gentoo type ext4 (rw,relatime)
proc on /mnt/gentoo/proc type proc (rw)
tmpfs on /mnt/gentoo/run type tmpfs (rw)
/dev on /mnt/gentoo/dev type none (rw,bind)
/dev/pts on /mnt/gentoo/dev/pts type none (rw,bind)
/dev/shm on /mnt/gentoo/dev/shm type none (rw,bind)
/sys on /mnt/gentoo/sys type none (rw,bind)
/afs on /mnt/gentoo/afs type none (rw,bind)
/tmp on /mnt/gentoo/tmp type none (rw,bind)
/data on /mnt/gentoo/data type none (rw,bind)
/proc/bus/usb on /mnt/gentoo/proc/bus/usb type none (rw,bind)
[root@localhost ~]# cat /proc/mounts
rootfs / rootfs rw 0 0
/proc /proc proc rw,relatime 0 0
/sys /sys sysfs rw,relatime 0 0
udev /dev devtmpfs rw,relatime,size=3983184k,nr_inodes=995796,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
/dev/sda10 / ext4 rw,relatime,barrier=1,data=ordered 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
/dev/sda2 /boot ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
/dev/sda6 /var/cache/openafs ext2 rw,noatime,errors=continue 0 0
/dev/sda7 /var/fscache ext4 rw,noatime,barrier=1,data=ordered 0 0
/dev/sda13 /data ext4 rw,relatime,barrier=1,data=ordered 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
cgroup /cgroup/cpuset cgroup rw,relatime,cpuset 0 0
cgroup /cgroup/cpu cgroup rw,relatime,cpu,release_agent=/usr/sbin/cgroup_clean 0 0
cgroup /cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0
cgroup /cgroup/memory cgroup rw,relatime,memory 0 0
cgroup /cgroup/devices cgroup rw,relatime,devices 0 0
cgroup /cgroup/freezer cgroup rw,relatime,freezer 0 0
cgroup /cgroup/net_cls cgroup rw,relatime,net_cls 0 0
cgroup /cgroup/blkio cgroup rw,relatime,blkio 0 0
/etc/auto.misc /misc autofs rw,relatime,fd=7,pgrp=2766,timeout=300,minproto=5,maxproto=5,indirect 0 0
-hosts /net autofs rw,relatime,fd=13,pgrp=2766,timeout=300,minproto=5,maxproto=5,indirect 0 0
/etc/auto.gsa /gsa autofs rw,relatime,fd=19,pgrp=2766,timeout=300,minproto=5,maxproto=5,indirect 0 0
/etc/auto.gsaro /gsaro autofs rw,relatime,fd=25,pgrp=2766,timeout=300,minproto=5,maxproto=5,indirect 0 0
AFS /afs afs rw,relatime 0 0
gvfs-fuse-daemon /home/theUser/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=nnnn,group_id=nnnn 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
/dev/sda9 /mnt/gentoo ext4 rw,relatime,barrier=1,data=ordered 0 0
proc /mnt/gentoo/proc proc rw,relatime 0 0
tmpfs /mnt/gentoo/run tmpfs rw,relatime 0 0
udev /mnt/gentoo/dev devtmpfs rw,relatime,size=3983184k,nr_inodes=995796,mode=755 0 0
devpts /mnt/gentoo/dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /mnt/gentoo/dev/shm tmpfs rw,relatime 0 0
/sys /mnt/gentoo/sys sysfs rw,relatime 0 0
AFS /mnt/gentoo/afs afs rw,relatime 0 0
/dev/sda10 /mnt/gentoo/tmp ext4 rw,relatime,barrier=1,data=ordered 0 0
/dev/sda13 /mnt/gentoo/data ext4 rw,relatime,barrier=1,data=ordered 0 0
/proc/bus/usb /mnt/gentoo/proc/bus/usb usbfs rw,relatime 0 0
[root@localhost ~]# |
As mentioned, the host is RedHat 6.2, so things may be done a bit differently. I commented the various privilege reductions for /cgroup after first seeing the error message, figuring that perhaps there was some sort of mount/function mismatch between RedHat and Gentoo. But clearly /cgroup is there, and my scheduler is using it.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 6827
|
| Posted: Thu Dec 08, 2011 2:55 am Post subject: |
|
|
| depontius wrote: | | Yes, I believe I stated that after my first experiment. |
You did, but I did not want to assume that there was no change between that post and the post where the error appeared.
I normally mount a single cgroup that has all the cgroup options, rather than one mount per cgroup option. |
|
| Back to top |
|
|
depontius
Veteran
Joined: 05 May 2004
Posts: 1925
|
| Posted: Thu Dec 08, 2011 1:46 pm Post subject: |
|
|
| Hu wrote: | | depontius wrote: | | Yes, I believe I stated that after my first experiment. |
You did, but I did not want to assume that there was no change between that post and the post where the error appeared.
I normally mount a single cgroup that has all the cgroup options, rather than one mount per cgroup option. |
I'm "just using RedHat 6.2", and this is the way things have been set up. I'm also starting with the RedHat lxc package, so I would have expected it to expect the RedHat 6.2 style of multi-mounting /cgroup, as well. However I am running a corporate tweak of RedHat 6.2, but I don't think they would have deviated on something this fundamental. I'm here in a Gentoo list talking about RedHat because I'm wanting to put Gentoo in the lxc container, and eventually reverse that situation.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 6827
|
| Posted: Fri Dec 09, 2011 4:00 am Post subject: |
|
|
| I understand that. However, the single vs. multi-mount cgroup is an obvious difference between them, which can easily be changed temporarily to see if it works. |
|
| Back to top |
|
|
depontius
Veteran
Joined: 05 May 2004
Posts: 1925
|
| Posted: Fri Dec 09, 2011 12:38 pm Post subject: |
|
|
| Hu wrote: | | I understand that. However, the single vs. multi-mount cgroup is an obvious difference between them, which can easily be changed temporarily to see if it works. |
Later today I'll shut down "speedy200", remount /cgroup, and give it a shot.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
