-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Herbert Poetzl schrieb: > On Tue, Aug 26, 2008 at 09:48:06AM +0200, Oliver Welter wrote: >>>> I put the aufs mount in the guest fstab: >>>> none / aufs dirs=overlay:rootfs=ro 0 0 >>>> >>>>> that's the correct way to do it (fstab.remote for >>>>> network related mounts) >>>> When I launch the guest, I get: >>>> vcontext(/dev/null) permission denied >>>> >>>>> looks like your /dev/null is not accessible, >>>>> try to add an explicit 'dev' to the fstab, >>>>> IIRC, the fstab mounts are executed 'securely' >>>>> which means they add 'nodev' if not specified >>>>> otherwise ... >>>> Anybody has a working setup? >>>> >>>>> no, why would one do that, when there is something >>>>> like unification available, with a lot of advantages >>>>> over such an overlay setup ... > > > I explained my setup here several times and I did not find > a way to make this work using unification. > >> any specific reference where I can read up on that? Some basics are in the old wiki http://oldwiki.linux-vserver.org/advanced+DRBD+mount+issues The rest is spread over several list posts I guess - I will give you a short conclusion: I use vserver to failover/loadbalance webservers in combination with drbd. I have one "master" image for the apache stuff that is used by a dozend if vserver guest (readonly). The configs and user data as well as /var is mounted from a drbd disk, one for each guest. > The "share a common root" might work with unification but > puts a bunch of work on each update, as I have to care > about config files and correct packaging > (what is not that easy in gentoo) > >> what's the point in having a 'shared' root? >> if you have the overlay there, changing the original >> will give you strange effects, no? > >> just an example: > >> - /bin/bash (depending on libc.so.5) >> - in the overlay, somebody rebuild it with a different >> config, so it gets stored there >> - the template is updated to a new bash which >> links to libc.so.6 now >> - the bash in the overlay is broken I do updates always on the base system, never on the overlay, the overlay should contain just config data >> and with unification, you can clone the guest in a few >> seconds, do all the updates and testing, and when it >> works, you simply switch the dirs Currently I use symlinks from the root to a data disk which is a lot of PITA to fix after each update, I wont get rid of this with unification > Besides - it puts an extra level of security to the system > as you can easily see writes to places where they should > not happen. > >> and looking for files with the cow flags removed will >> show you the same as the overlay data I never looked at cow, so you might be right on this. Oliver - -- Protect your environment - close windows and adopt a penguin! PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF 8168 CAB7 B0DD 3985 1721 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIs9Tcyrew3TmFFyERAtYOAJ9rWvXAzX1IrhXPyE9xcYSYCFJ1jACeKp45 O28MAOJnSeY9npX8sJwt28M= =1Njj -----END PGP SIGNATURE-----