On Thu, May 21, 2009 at 04:55:15PM +0800, Edward Pilatowicz wrote:

> File storage objects:
>     path:///<file-absolute>
>     nfs://<host>[:port]/<file-absolute>
> Vdisk storage objects:
>     vpath:///<file-absolute>
>     vnfs://<host>[:port]/<file-absolute>

This makes me uncomfortable. The fact it's a vdisk is derivable except
in one case: creation. And when creating, we will already want some way
to specify the underlying format of the vdisk, so we could easily hook
the "make it a vdisk" option there.

That is, I think vdisks should just use path:/// and nfs:// not have
their own special schemes.

> In order to avoid root squashing, or requiring users to setup special
> configurations on their NFS servers, whenever the zone framework
> attempts to create a storage object file or vdisk, it will temporarily
> change it's uid and gid to the "xvm" user and group, and then create the
> file with 0600 access permissions.

Hmmph. I really don't want the 'xvm' user to be exposed any more than it
is. It was always intended as an internal detail of the Xen least
privilege implementation. Encoding it as the official UID to access
shared storage seems very problematic to me. Not least, it means xend,
qemu-dm, etc. can suddenly write to all the shared storage even if it's
nothing to do with Xen.

Please make this be a 'user' option that the user can specify (with a
default of root or whatever). I'm pretty sure we'd agreed on that last
time we talked about this?

> Additionally, whenever the zones framework attempts to access an storage
> object file or vdisk it will temporarily switch its uid and gid to match
> the owner and group of the file/vdisk, ensure that the file is readable
> and writeable by it's owner (updating the file/vdisk permissions if
> necessary), and finally setup the file/vdisk for access via a zpool
> import or lofiadm -a.  This should will allow the zones framework to
> access storage object files/vdisks that we created by any user,
> regardless of their ownership, simplifying file ownership and management
> issues for administrators.

+1 on this bit, for sure.

> For RAS purposes, we will need to ensure that this vdisk utility is
> always running.  Hence we will introduce a new lofi smf service
> svc:/system/lofi:default, which will start a new /usr/lib/lofi/lofid
> daemon, which will manage the starting, stopping, monitoring, and
> possible re-start of the vdisk utility.  Re-starts of vdisk utility

I'm confused by this bit: isn't startd what manages "starting, stopping,
monitoring, and possible re-start" of daemons? Why isn't this
svc:/system/vdisk:default ? What is lofid actually doing?

zones-discuss mailing list

Reply via email to