Robert.Thurlow at sun.com wrote: > > 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? --Glenn
