I tend to agree, and the basic "server consolidation" target just makes
sense.  I want to pretend a zone is the box I used to have and not have
to bump my nose on a funny behaviour or exceptions.

However, there are some wrinkles:

2) Due to the above, it seems like the global zone admin should have
a knob to turn to enable or disable the ability of a zone to share
out files via NFS.  Do people agree?

For Trusted Extensions we generally don't want policy decsions, like what can be shared, to be made outside of the global zone. Therefore, a knob seems like a good idea.

3) I know we've talked about a zone not being able to share stuff
outside of its namespace, but I wonder if we should further restrict
this to sharing storage that's fully administered in the zone, e.g.
you can't share a filesystem you got via lofs, but you can share
from a /dev/dsk/cxtxdx or a zpool that had been fully delegated to
you.  Opinions?

This seems like a good idea. Of course the zone's root directory is a special kind of lofs mount that is established during zone_create, so directories in that filesystem should be sharable. Even if the zone is created using zfs, the dataset's root is not in the zone.

4) A bug currently prevents a client instance and a server instance
from being safe to use on the same box (apologies, can't quote the
bugid from here).  How likely, in your use case, is it that this will
be a problem, i.e. will your boxes be in the position where a zone
needs data shared from another zone as opposed to a separate server?

This is a must fix. In TX we want to automount between labeled zones on the same machine. It seems to work with ZFS. Is the deadlock specific to UFS/NFS?

zones-discuss mailing list

Reply via email to