On Wed, 2005-12-21 at 10:11, Cathy Zhou wrote: > >It's not immediately obvious to me that vanity naming, particularly > >of physical devices, is necessarily a good thing. I think you need > >to explain more clearly why this is a good thing. > > > This is discussed in the document: "vanity naming will prove especially > useful for machine migration, Zones migration and Dynamic Reconfiguration."
But those are relatively rarified cases - what benefits are there to the majority of users? > There is also an example specifically for DR, see section 3.1.4 on page > 5. Simply put: today, because the link name is tightly tied to the > underlying hardware, there is no way that you can remove bge0 and insert > ce0 then the system will just work. You have to replumbing the ce0 link, > update all related configuration to the new name... That's tedious and > it is very possible that you will leave out one or two configuration > with the old bge0 name by mistake. Well yes, but is vanity naming the way to do this? Why isn't it possible to have a utility that saves all the configuration associated with an interface, and then be able to apply that to the new interface? (Actually, that would be a handy tool to have in any event.) > >In particular, allowing physical interfaces to have their names > >altered could potentially lead to significant confusion. Normally, > >when looking at a machine, I instinctively associate the device > >name with a physical socket (which is where the cables go); the > >network is abstracted at the IP address level. > > > > > I would expect that there are only very few times that the administrator > needs to care about the physical attachment of a link. If they do need > to know about the device name, it can be displayed by the "dladm > show-phys" subcommand. This is absolutely key information for an administrator. It is *absolutely essential* that I be able to understand the physical connectivity, and to be able to get this information easily. And, currently, the dladm invocation is insufficient. > >What is to stop someone renaming bge0 to bge1, and bge1 to bge0? > >And how do you make it obvious that bge0 and bge1 are now the > >wrong way round? > > > > > ... except *nobody* would reasonably configure like that. Unfortunately, the world isn't an ideal place, and not all administrators share the same values. > Note that > vanity naming doesn't mean that administrators should rename links > randomly and frequently. Provide the capability, and it will be abused. > >(Why does the name of the underlying device need to be changed? > > > You mean the link name, right? The name of the underlying device will > not be able to be changed. If administrators doesn't want any vanity > link name, no extra configuration will be needed and the physical link > will be assigned the default name, which will be the same as the device > name. Nothing will be changed. OK, I'll try to ask the question somewhat differently. Why change the link name at all? Why not provide the ability to define a logical alias to which all configuration can be applied? Then the link names never change at all, which saves a lot of work and confusion. But, by associating configuration with the alias rather than the physical device you get the abstraction required. > >I'm unclear as to what happens to the kstats. In particular, what are > >the names? Currently, I can access the statistics for bge0 through > >bge:0:bge0 - is this unchanged? Or does the name of this change > >to bge:0:net/bge0 (which is how I read the document). > > > Yes. Yes to which? > >Or are their now two kstats - one for the physical > >link and one for the vanity name? > > > Yes, one with the device name, and another with the link name. The > former will be kept to preserve the backward compatibility. This introduces a couple of problems (and a further question): - is there a performance impact of keeping duplicate kstats? It seems to me that there is an unnecessary cost here. - there is a risk of confusion here, as tools see the data twice and can end up counting traffic twice. And the question: what happens to the data associated with the vanity kstat if it gets moved to another physical interface? Is it just forgotten about? Or can the historical data embedded in the kstat be transferred across? > >What do tools such as netstat and ifconfig show for the interface name? > >Currently, they show bge0 or similar. Will they follow the net/net0 > >scheme, or just show net0? > > > They will just show "net0". Ah. So there will be no indication whatsoever whether this is the default (ie. physical) link-name or a vanity name? > >Would it be possible for (an extra flag may be needed) for ifconfig > >and similar tools to show the physical device names? > > > Why? The big point of vanity naming is to make the high level > configuration independent from the underlying hardware. However, an understanding of this maps onto the underlying hardware is essential. > >As I understand it, the way to connect the vanity names to physical > >names is using dladm show-dev. However, at present this requires > >privilege - so a normal user, or root in a zone, would not be able > >to do this. This could be a problem - when trying to work out > >networking problems on a system you may not have all privileges. > > > The device name will be able to be displayed by "dladm show-phys" > subcommand, which can be issued by any user, as long as he/she has the > sys_net_config priviledge. Unfortunately, that privilege also includes the rights to completely reconfigure any aspect of networking, so that isn't something that would be given to just any user. And certainly wouldn't be given out to a zone. Why is this information restricted? Why can't anybody see the physical layout? I would very much like to get this output without requiring any special privileges. Thanks for the responses! -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ networking-discuss mailing list [email protected]
