Peter Memishian wrote: > > > IMHO, it's also semantically incorrect: the original meaning of > "physical" > > > referred to the physical IP interface, which is of course quite different > > > from a link. Given all the work we've put into trying to untangle > > > datalinks and IP interfaces, I'm distressed to see them conflated. > > > > What does "it" refer to above? > > zonecfg. Depending on the value of "ip-type", "physical" has two > different meanings. > > > IP Instances does not conflate datalinks and IP interfaces. >
Expanding on this a bit. You are correct that the physical property in the net resource in zonecfg refers to conceptually different objects for shared-IP zones and exclusive-IP zones. And we're explaining that in the draft zones documentation (see e.g. http://docsview.sfbay/doc/819-2450). 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. 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. Erik
