Subject: Re: [vserver] sharing /vserver
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Thu, 4 Sep 2008 06:10:40 +0200

On Wed, Sep 03, 2008 at 05:25:00PM -0400, Edward Capriolo wrote:
> I did mean glusterFS. 
> Now I have a questions about the file system flags.
> 
> Suppose a VServer that has four physical disks.

you mean a Linux-VServer Host, yes?

> /mnt/disk1  formatted ext3 /dev/hda1
> /mnt/disk2  formatted ext3 /dev/hda2
> /mnt/disk3  formatted ext3 /dev/hda3
> /mnt/disk4  formatted ext3 /dev/hda4
> 
> If i built a vserver named test with a rootdirectory of /mnt/disk4, 

you mean a Linux-VServer Guest here, I presume 

> it would get installed to /mnt/disk4/test. The 'quota' would be 
> the fact that test could fill up disk4.

that would definitely be the 'upper' bound

> Question 1: The guest test is locked inside /mnt/disk4 
> The guest has no access to disk1, disk2, disk3. True or False?

depends, assuming that the barrier on /mnt/disk4/test/..
is intact, this will be true

> Question 2: If test2 was also installed to /mnt/disk4/test2 could 
> that guest affect test1?

again, depends on the setup. given that:

 - the barrier for both guests is intact
 - disk limits (per guest) are set so that
   one guest cannot go over e.g. half of the
   disk space

they will only affect eachother marginally
(shared I/O path and file allocations)

HTH,
Herbert

> On Wed, Sep 3, 2008 at 2:30 PM, Herbert Poetzl <herbert@13thfloor.at> wrote:
> > On Wed, Sep 03, 2008 at 01:21:27PM -0400, Edward Capriolo wrote:
> >> I do not need the quota capabilities built into vserver.
> >> I plan on giving each vserver its own logical volume.
> >
> > your decision, but some folks like the disk, memory
> > and time saving benefits of the unification approach
> >
> >> I do not see why that volume could not be on a gluster FS.
> >
> > do you mean 'cluster' or really 'gluster' fs?
> >
> > for the former, no problem, as long as the filesystem
> > supports the necessary flags, otherwise you'll end
> > up with insecure guests, for the latter, I'm pretty
> > sure that won't work out of the box
> >
> >> I have not tried yet.
> >
> > let us know how it goes, when you do ...
> >
> > best,
> > Herbert
> >
> >> On Wed, Sep 3, 2008 at 6:18 AM, Herbert Poetzl <herbert@13thfloor.at> wrote:
> >> > On Wed, Sep 03, 2008 at 11:15:10AM +0200, Oliver Welter wrote:
> >> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> >> Hash: SHA1
> >> >>
> >> >> Hi
> >> >>
> >> >> ADNET Ghislain schrieb:
> >> >>
> >> >> > I wanted to share my /vserver between a bunch of host to be able
> >> >> > to run a vserver from any host (not launch one on several host
> >> >> > at the same time ). the goal is to use unification on all the
> >> >> > vservers also.
> >> >> >
> >> >> > I have a SAN setup so how do you handle this to have the best
> >> >> > performances ? Use a simple NFS server, a ocfs2 partition shared
> >> >> > on all the nodes, a glusterfs one ?
> >> >> >
> >> >> Just to put an idea - I "share" my guest rootfs readonly simply by
> >> >> having an rsync between the boxes on updates, which occure only
> >> >> if I patch/update a server. You might even automate this using
> >> >> inotify. The guest data is pulled in by an extra replicated disk
> >> >> - as I have only two nodes, I use drbd, but you can use any other
> >> >> clusterfs here too. So you do not need to find a fs that supports
> >> >> unification.
> >> >
> >> > depending on _how_ you share the 'root fs' it might
> >> > destroy the benefit of unification ...
> >> >
> >> > I'd be interested in the output of 'stat /bin/bash'
> >> > (assuming that /bin/bash is shared) for two guests
> >> > on the same host
> >> >
> >> > best,
> >> > Herbert
> >> >
> >> >> 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
> >> >>
> >> >> iD8DBQFIvlWeyrew3TmFFyERAklAAJ45+9mxuHO25t5aumXUue/udnM4WwCeO+hG
> >> >> LxX00wCQ9eBQ6AgLf3RToeI=
> >> >> =LmgE
> >> >> -----END PGP SIGNATURE-----
> >> >
> >