>> 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. > > The problem will arise if: > - the physical link is renamed in the time between it being > written into the store ($xp/bridge) and being read by the > hotplug script. This is typically less than a second and not > more than 15 seconds. > - the identified link ($xp/nic) is renamed between it being > written into the store and examined by xnbo or qemu-dm. This is > typically less than a second. > > So, whilst the window is small, it could be seen. > Understood. But it seems that the first problem will not be able to be eliminated as $xp/bridge is well known, as you mentioned below. :-(
>> 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? > > qemu-dm also opens $xp/nic (using libdlpi) when HVM is used with IO > emulation. > > It's worth noting that $xp/bridge is "well known", in the sense that > it exists and is used by the reference implementation, although it has > a slightly different meaning there (it's the name of a software > ethernet bridge (e.g. xenbr0)). $xp/nic is a local invention. > > Given that $xp/bridge is known by python code and is currently a > direct passthrough of the "bridge" arguments of a vif, having it > suddenly morph into a linkid feels bad. > > $xp/nic could change without any significant problems, though > observability would suffer a little. > Assume we only change $xp/nic to use linkid. We need to change: a. qemu-dm needs to call libdladm API to convert linkid to link name before it calls libdlpi to open the link. b. v_add() needs to print the linkid of the VNIC as the output, and v_remove() needs to take linkid of the VNIC as the input argument. c. the vif-vnic script needs to change to write/read $xp/nic as linkid. d. the vif-dedicate script needs to convert $xp/bridge to a linkid and write it to $xp/nic. e. the xnbo driver using the linkid (read from $xp/nic) to get the mac name and open the mac. What else? Thanks - Cathy
