> You might ask yourself why not use a different property (such as > "linkname") in the exclusive-IP case. > > The reason for that has two facets. First of all the net resource is at > a higher abstraction level than either the IP interfaces or datalink > names; it loosely defines a zone's attachment to the network.
Indeed. > At that level of abstraction whether something is implemented using a > logical interface in the global zone or as a separate datalink name > (real or a vnic created on the fly) is an implementation detail. We've > talked about replacing the implementation for this in Nevada so that we > can simplify the code base and also provide a fuller feature set. That > can take several directions but the discussions have included > - using 'physical' as the base NIC on which a vnic is created on the fly > - removing the need for 'physical' when an IP address is specified, > since what we currently claim to support is the case when that IP subnet > is also configured in the global zone thus the system can determine it > on the fly. > > If any of those come to fruition then it would have been a mistake to > add e.g. a 'linkname' property which we guarantee to be the datalink name. I don't quite see this. We can have any number of properties under the "net" resource. It may be that some only apply in certain types of configurations. -- meem
