On Thu, Sep 27, 2007 at 02:35:08PM +0800, Cathy Zhou wrote:
> 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.
Seems fine.
> 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.
> 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.
