Hi David, As we discussed, there would be several changes needed to make UV work with xVM. Here is a summary of the proposed changes based on my understanding:
a. The concept of VNIC ID will be removed, and when v_add() creates a new VNIC, it will automatically assign a vnic<N> link name to the new VNIC. As part of this change, the v_add() function can print the name of the new VNIC name as the output (instead of the VNIC id today), and v_remove() funtion takes the VNIC name as the input argument (today it is VNIC ID). Accordingly, the sunos.hg/src/scripts/vif-vnic in the xVM gate needs to be changed. b. Further, as we discussed, I am considering whether we are able to eliminate the impact of "dladm rename-link" to an existing xVM configuration. This work is not required, but we will have to document carefully that "dladm rename-link" might make the xVM configuration out of sync. Anyway, let's think about what changes need to be made to make xVM work with vanity naming and what impact it would cause, before we decide whether or not to make those changes: When a guest domain is created, either a dedicated physical link or a VNIC can be assigned. The former is kept as $xp/bridge, and the $xp/bridge is also be used to create the VNIC. The dedicated physical link or the VNIC is kept as $xp/nic. Either the physical link or the VNIC can be renamed, and once they are renamed, the xVM configuration will be out of sync with the link name configuration. We could keep linkid for $xp/bridge and $xp/nic in the xVM storage in order for the configuration to survive a renaming operation. If we do that, we will need to change the v_add() function to take the linkid of the link that a VNIC will be created on. Further, the xnbo_hotplug() function will also need to convert the linkid to a mac name and open that MAC. I am not sure how much changes need to be made to xVM gate though, and I am little concerned that this would introduce too much difference from the main Xen code base. What do you think? Thanks - Cathy
