James Carlson wrote:
> Needless to say, there are a few sharp edges here for the unwary user.
> The original design goal of Zones was simply for consolidation on
> shared networks, not separated ones, and stepping outside of that has
> been a fairly persistent source of pain.
Yes, there was a reason that I spent some time to build the exclusive-IP
zone support; to many cases of trying to push the shared-IP zones
outside of their original design center.
But it will take some time before the customers that need this
flexibility can move over to using exclusive-IP zones; what is important
is that we work actively to remove any obstacles to using exclusive-IP
zones. (I believe we have some work to do for TX here.)
>> Would it make sense to somehow restrict this property to the case when
>> the ngz has IP address(es) that do not have a common subnet with any
>> other zone on the system?
>
> If the "restriction" is in the documentation provided for the feature,
> then I would agree. Otherwise, I have to agree with Glenn that static
> checks against the configured zones don't necessarily do the right
> thing, as users are under no obligation to boot and run all installed
> zones all of the time.
We do know that there is a number of users that will benefit from this -
those that use different subnets for different zones (whether or not
they use TX).
But what is hard to predict is to what extent other users will end up
trying to use this feature and call us when it doesn't work.
I wouldn't mind seeing the draft documentation changes (and commitment
from the docs/man page folks to ship those) before we ship the
implementation.
Erik
