On Wed, Jan 30, 2008 at 03:07:06PM -0800, Edward Pilatowicz wrote:
> 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.)
While you're obviously correct, I prefer to use the provided mechanisms
where they exist. I agree with everything you've said, I would just
prefer that the second clause below weren't the case:
> 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.
Just a statement of preference, that is all.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080130/06d061e6/attachment.bin>
