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
- by default VNICs will be automatically configured by NWAM as they are
created, and
- 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?
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]
_______________________________________________
networking-discuss mailing list
[email protected]
