The dladm_walk() done when NWAM starts up and generates the events to create
the NCUs only walked the physical links:

    (void) dladm_walk(ncu_create_link_action_event, dld_handle, NULL,
        DATALINK_CLASS_PHYS, DATALINK_ANY_MEDIATYPE, DLADM_OPT_ACTIVE);

Changing the walk to include VNICs creates the NCUs for the VNICs:

    (void) dladm_walk(ncu_create_link_action_event, dld_handle, NULL,
        DATALINK_CLASS_PHYS | DATALINK_CLASS_VNIC, DATALINK_ANY_MEDIATYPE,
        DLADM_OPT_ACTIVE);

The VNIC NCUs are created only when NWAM (re)starts.  No events are received by
NWAM when the VNICs are actually created with NWAM running.

We understand why vnics are not discovered on start but we havn't discovered
why/how we discover them when they are created after start. I think we should
either see them and deal with them correctly or not at all.  So at the moment I
think vnic support of any type should be a post integration RFE.

In addition to the concern Michael raised about not being able to recognize
vnics when they are initially created (because a sysevent is not created,
as is the case when a physical device is inserted), I'm also concerned about
setting precedent for the way nwam manages vnics before we've fully thought
it through.  One obvious issue is that vnics are tied to underlying physical
links; if nwam treats them simply as physical links, we don't have a way of
tracking that relationship.

However, there is also a concern that if nwam's start method simply creates
vnics (with the 'dladm up-vnic' call), but nwamd itself does not manage vnics,
how will users create persistent vnic configuration?

For now, the proposed solution will be user-created ENMs which can be
automatically activated by nwam, and can create the desired vnic configuration.
More general support for vnics, vlans, and aggrs will be added to nwam in the
future.  I'm changing this to an RFE to track that work.