On Wed, Jan 30, 2008 at 10:14:21PM +0000, Ceri Davies wrote: > On Wed, Jan 30, 2008 at 09:37:28AM -0800, Edward Pilatowicz wrote: > > On Wed, Jan 30, 2008 at 09:27:07AM -0500, James Carlson wrote: > > > Erik Nordmark writes: > > > > However, if the ngz's shares a subnet with some other zone, then the > > > > current logic in the kernel isn't capable of supporting a different > > > > default route for different zones. This is because the kernel check is > > > > whether the gateway field in the default route is on the same subnet as > > > > one of the zone's IP addresses. > > > > > > There's another problem buried here, which is that the proposed > > > feature doesn't delete the static routes when the zone is shut down. > > > It doesn't delete them because it's trying to cover for the EEXIST > > > case. > > > > > > I think the right thing to do is to remember when the "route add" > > > attempt fails, and conditionally remove the route on zone shutdown. > > > That potentially leaves a zone relying on a duplicate out in the cold, > > > but since it's a misconfiguration anyway, it doesn't seem like a big > > > problem. > > > > this seems sloppy. i think that when zones are shutdown they > > should remote any default routes that they installed. > > > > and if it's a misconfiguration to boot two zones with the same > > default route then we shouldn't allow multiple zones to boot into > > this state. instead when the user boots subsequent zones that would > > have overlapping default routes we should generate an error message > > telling the user that the configuration is incorrect. > > That sounds like it would cause a regression for us. > > We currently have dedicated interfaces for some zones; these zones live > on the same subnet, one which is not intended to be used by either other > local zones or the global zone. Since they are on the same subnet, they > have the same default route and there isn't a problem. We use VCS Zone > agents to online the zones and postonline triggers to bring the routes > online; deleting the routes when the zone is shut down isn't really a > problem in our situation because we don't care if it's there. > > Basically what I'm saying is that not having the route removed on zone > shutdown is a much smaller problem than not being able to share a > default route between zones which would basically disrupt our entire > infrastructure. I don't expect you to do what we want, but just wanted > to throw this out as a data point; in short, we are already rolling our > own solution to the "routes for zones" problem and would rather that it > not be fixed if that is going to introduce new limitations elsewhere. >
this would not be a regression for you. since you're already doing this you've obviously worked around the problem. your workaound should continue to work regardless of the changes introduced by this proposal. (if it wouldn't i'd be curious to see why.) the way this would impact you is if: - you tried to remove your workaround and use the new defrouter zonecfg method - and that method did not allow multiple zones to use the same route. having new functionality that doesn't fullfuill your requirements is hardly a regression. (otherwise i'd ask the zfs team to fix my desktop problems with their next RFE.) james carlson said he was ok with allowing the user to create these types of configurations, but then just documenting that they are unsupported. i disagree. already we've had two people (you and ken) say that you plan to use this configuration that would be documented as unsupported. if there's such a strong requirement for this configuration then this proposal should either address it or prevent it. you can always continue to use your current workaround. also, i'm not saying that we can't shouldn't support this type of functionality. but if we want to support it then i'm saying we should do it correctly and associate the routes with the zones that depend on them such that when all the zones which use the same default route go away, so does that default route. ed
