Darren Reed wrote:
> There's at least a man page bug because the documentation for > create-vnic in dladm(1m) doesn't mention that the vnic is tied > to the MAC address of the NIC. The impression that you get is > that by saying "-l e1000g0", you the vnic you are creating to > the thing with the *name* e1000g0. Maybe we need the equivalent > of "soft" vs "hard" links with vnic's and interface names? > e.g. a "soft link" with dladm ties a vnic to the named interface > (c.f. "ln -s foo bar" but a "hard link" with dladm ties it to > the MAC address (like "ln foo bar" does with inodes.) The VNIC is not tied to the MAC address of the underlying NIC unless the underlying NIC provides multiple hardware factory MAC addresses, which is not the case for e1000g. If you create a VNIC on e1000g and don't specify a MAC address value, we'll generate a random MAC address and assign it to the VNIC. If later you delete and re-create a VNIC on top of that same NIC or a different NIC, a new random MAC address will be generated regardless. The random MAC address associated with a VNIC will be persistant across reboot as long as you don't delete and re-create that VNIC. The single factory primary MAC address of the underlying NIC will be used only when plumbing the interface, when creating VLAN data-links on top of the NIC, and by aggr for LACP traffic or if automatic MAC address assignment is specified. So the issue is not the MAC address, the issue is the association between the VNIC and the underlying data-link, not the data-link name. Note that the same is true for all pseudo links, aggr, VLAN, etc, so it's not an issue specific to VNICs. I'm not convinced that having the association be with the name of the data-link would be any better, since that approach would have his own set of issues. Nicolas.
