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?
Administrators will be able to give the network links meaningful names
if they like. Again, if they don't want vanity naming at all, no
configuration will be needed and the system will behave exactly the same
as today.
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.)
Right, assuming we had such tools, it might solve the problem. But keep
in mind that network configuration could be anywhere: configuration
files, the SMF repository, or even just embedded in the file name (for
example, hostname.*). Also, how to migrate the configuration of some
third party applications? This is not a easy effort.
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.
I agree that the physical connectivity is important. But with vanity
naming in place, it doesn't prohibit you from knowing that information.
Actually dladm could help you to figure out the connection of each link
by displaying the link state of each link.
... except *nobody* would reasonably configure like that.
Unfortunately, the world isn't an ideal place, and not all
administrators share the same values.
ote that
vanity naming doesn't mean that administrators should rename links
randomly and frequently.
Provide the capability, and it will be abused.
Well, I don't know what we can do if privileged users do such things
only to confuse themselves.
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.
How to associate configuration with the alias? Does that mean
appliations will then access the link by opening the alias instead of
the link name? I guess the alias should be in the different namespace
from the link name. So that the open() API needs to indicate somehow
that it is openning an alias, not a link name? I might miss something
but I don't see how it going to work.
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?
Sorry that I wasn't clear. Yes, there will be a kstat named "net/bge0".
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.
No, there is no extra cost. It actually involves the implementation of
kstat: simply speaking, the kernel will only track the statistics once,
but both kstats will query the same set of statistics data in the kernel.
- there is a risk of confusion here, as tools see the data twice and
can end up counting traffic twice.
See above. And what do you mean that the tools will see the data 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?
Assume that at first net0 is associated with ce0. If then net0 is
asssoicated with bge0, its kstat will only indiate the statistics value
of bge0. There is no history issue.
Or can the historical data embedded in the kstat be transferred
across?
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?
No. I don't see obvious reason why applications like ifconfig care about
whether it is default name or not. If administators need to know the
mapping, they can compare the link name with the device name displayed
in "dladm show-phys".
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.
Okay. Again, one can figure out the mapping using "dladm show-phys".
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 to point it out. It appears that this is a bug, see
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6219893.
Thank you very much for your input!
- Cathy
_______________________________________________
networking-discuss mailing list
[email protected]
