On Sep 8, 2009, at 6:55 PM, Renee Danson Sommerfeld wrote:
On Thu, Sep 03, 2009 at 05:30:35PM -0700, Nicolas Droux wrote:
Renee Danson Sommerfeld wrote:
On Mon, Aug 31, 2009 at 07:33:31AM +0300, Cyril Plisko wrote:
Yes, this is why the interim fix is not happening. ?The nwam
daemon
needs to be changed so that it explicitly ignores the vnics, and
while
Renee,
I think ignoring interfaces should be an explicit decision made
by human,
rather than based on their type. In the same scenario that
discussed in
this thread there could be physical interface that is used
exclusively
in the zone. In that case I may need to tell nwam to ignore it as
well,
so it must be configurable.
Can you please tell how is it handled in nwam phase 1 ?
The reason vnics are singled out by type and ignored is because
the only
thing nwam could do with them in phase 1 is treat them as ordinary
physical
links. This might be fine for some case; but it limits our
ability to do
more with them moving forward.
However, phase 1 will give you far more flexibility in determining
how
the physical interfaces are managed. We introduce a profile that
contains
rules for configuring links and interfaces on a system, called the
Network
Configuration Profile (NCP). By default, the Automatic NCP will
be active,
which will follow the same policy as the current nwam: configure one
active interface at a time, preferring wired over wireless. But
you will
also be able to create and enable your own NCP, which can
implement a
very different policy. There will be a GUI and CLI tools to
manage these
profiles.
I'm still not clear on what this means concretely for the case being
discussed here. Are you saying that:
- persistant VNICs and etherstubs will be instantiated at boot time
when
NWAM is enabled, and
Yes.
- by default VNICs will be automatically configured by NWAM as they
are
created, and
No.
- In order to avoid NWAM to configure VNICs (for example when they
are
assigned to a zone or VM) we have to configure a new profile?
No.
The second paragraph I wrote was in response to Cyril's question about
management of physical links (I was imprecise in the first sentence, I
should have said "physical links" rather than "physical interfaces";
however, my intent was to distinguish between physical links and
vnics).
As I said, NWAM phase 1 will ignore VNICs. They will not show up in
the Automatic NCP.
At the request of folks who (as I understand it) wish to have VNICs
created on a system which is running NWAM, the start method for the
nwam
service will be instantiated at boot time, just as they are in the
start
method for network/physical:default (the alternative to nwam). But
because NWAM phase 1 does not yet have the flexibility to manage VNICs
and etherstubs and other advanced link types, those links will be
ignored, and not added to the Automatic NCP.
That is a major pain point right now, so that will help.
Are you also going to instantiate user-flows when is NWAM enabled?
These should be simpler to handle since they should be transparent to
NWAM.
If users wish to create their own configuration in a User NCP, it is
possible to add VNICs there; however, they will be treated by NWAM
exactly as other physical links. They must still be created using
dladm.
And conversely it will be possible to configure a User NCP which
allows the administrator to instruct NWAM to not plumb and configure
other (possibly non-VNIC) data links?
It would be nice in the future to make this more automatic, i.e.
instead of using the data link class, query the zone/VM configuration
to determine whether a data link should be plumbed/configured by NWAM
in global zone/dom0.
Nicolas.
Does this help?
-renee
Or do you mean something else? A simple example showing how this
would
be achieved would be useful.
Nicolas.
You can take a look at the phase 1 spec at
http://opensolaris.org/os/project/nwam/p1spec/
The first few sections probably have the type of information you're
looking for.
-renee
this is still a fairly obvious code change, the test impact
becomes
much higher. ?It's code that happens early in boot, and can be
affected
by first-boot-ater-install differences, which expands the test
scenarios
pretty significantly.
(and a further confession: at the time the decision not to do the
interim fix was made, we thought nwam phase 1 would go in sooner
than build 127; but it's been delayed. ?We are making really good
progress now, though, and the 127 target still looks very good.)
-renee
--
Regards,
Cyril
------------------------------------------------------------------------
_______________________________________________
networking-discuss mailing list
[email protected]
--
Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc.
[email protected] - http://blogs.sun.com/droux
_______________________________________________
networking-discuss mailing list
[email protected]
