On 12/06/2012 8:48 PM, Jim Klimov wrote: > 2012-06-12 4:32, Darren Reed wrote: > ... >> >> To throw out some architectural questions... >> >> Does the existence of a shared networking stack require the existence of a >> zone configured with an exclusive networking instance or should networking >> instances be managed independently of zones? > > I think that is what the GZ is for. It spawns NICs and VNICs for > the exclusive stacks, aliases for shared stacks, etherstubs for > both :) I think GZ should be the one that spawns the (generic?) > IP stacks and attaches a zone (including a GZ) to one stack. > I did not read the source, but I believe that an exclusive stack > is created by the GZ at about the same time that the GZ forks off > a local zone to use this stack; at least, this would only make > sense :) > > I am not sure now that we need more than one IP stack in one > zone - when we can freely create zones and spawn a few for > routing over a private etherstub if need be - though there > might be uses for several stacks in a zone too, like multiple > VRF tables in a Cisco switch with explicit routing injection > into a VRF and an interface/subnet (but THAT's overcomplication, > I agree).
Currently open source virtual routing support has been implemented through the provision of multiple routing tables within the same network environment. A better problem description is required to fully understand whether the VRF functionality is best served by either multiple routing tables (per zone) or using multiple complete networking instances, although I suspect that it is the former. > >* How does the system behave when you shutdown the zone which > > owns the networking instance that is being shared (assuming > > that was the model used)? > >* Do all of the zones sharing it also need to be shutdown? > >* What about if you then want to destroy the zone that "owns" > > the networking instance? > > I assumed this model is not used, and the GZ owns all system > resources, including IP stacks, and delegates access (maybe > some control) to these objects to its local zones. > > Not necessarily the GZ itself *uses* all of these resources - > just like it does not by itself use a VNIC delegated into an > ip-type=exclusive local zone today. > > Basically, "an IP stack" becomes the conceptual networking engine > domain where fast-pathing and shortcuts for routerless connection > can take place - like is done for shared stacks today. If there > is one consumer (zone), the stack is exclusive. If more consumers > are attached at this moment - the stack becomes shared. The present code is written such that a zone either gets networking resources from the global zone or has them available to it privately. A networking instance also only exists for the same lifetime as that of a zone. Well, that's not exactly true but it's the best I can do for a short description however the important point to note is that currently a networking stack cannot exist without a zone. If I read what you're proposing above then aside from the global zone, what you want to do is take the network instance away from being part of the zone and instead assign them to a zone with the restriction of a zone only being allowed to have a single network instance assigned to it at any one time. That would continue to support exclusive instance zones where zone creation would also result in a networking instance being created for that zone. The difference to what exists today is that it would be possible to create a network instance and share that amongst a number of zones. Have I understood you right? If so then that rather dramatically changes the scope of work from what I think most people were thinking of and that is being able to use a zone as a "network master" for a number of other zones (call them slaves for now) where the slave shares one master's networking instance. Darren ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
