[EMAIL PROTECTED] 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 _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
