If zonecfg determines that the target fs type is nfs it will error and not
allow the zone to be configured. You can jump through hoops and do things to
hide that fact from zonecfg so it doesn't believe that the zone root is
running over nfs but I've got to think that it's not going to be well
tested, if tested at all.
Also, the blog you reference has the warning,
*"First let me say this is a workaround hack, we didn't do anything illegal,
and all the interfaces we used are regular Solaris interfaces, however it
comes dangerously close to the "don't do this at home folks" category. So
think twice before you'd use it in a production environment, but it
definitely fun to do."*
I'm not sure that I would feel comfortable running anything production
critical configured this way.
On Wed, Aug 19, 2009 at 6:03 PM, Henrik Johansson <henr...@henkis.net>wrote:
> Hello Michael,
> On Aug 19, 2009, at 7:17 PM, Michael Barrett wrote:
> Say you create a zpool based on a file that lives on a NFS mount. Then you
> mount that zpool to a local mount point and give it to your zone to live on.
> I'm assuming that under the covers this is just another version of this
> loopback method:
> Is there anyone out there running like this? Any performance issues that
> jumped out at you?
> Since using files as backing store for a pool is not recommended, putting
> them on NFS will probably not make things better. It will only be as
> reliable as the remote filesystem and NFS implementation together. People
> have lost their pools in far less complex configurations, talk to the ZFS
> people but i doubt they will approve.
> I would feel more safe with UFS if I where to put a filesystem on files or
> perhaps iSCSI:
> zones-discuss mailing list
zones-discuss mailing list