[libvirt] [RFC] [PATCH 3/3 v2] vepa+vsi: Some experimental code for 802.1Qbh

[Daniel P. Berrange]

On Sat, May 22, 2010 at 02:34:33PM -0400, Dave Allan wrote:
> On Sat, May 22, 2010 at 11:14:20AM -0400, Stefan Berger wrote:
> > On Fri, 2010-05-21 at 23:35 -0700, Scott Feldman wrote:
> > > On 5/21/10 6:50 AM, "Stefan Berger" <stefanb at linux.vnet.ibm.com> wrote:
> > > 
> > > > This patch may get 802.1Qbh devices working. I am adding some code to
> > > > poll for the status of an 802.1Qbh device and loop for a while until the
> > > > status indicates success. This part for sure needs more work and
> > > > testing...
> > > 
> > > I think we can drop this patch 3/3.  For bh, we don't want to poll for
> > > status because it may take awhile before status of other than in-progress is
> > > indicated.  Link UP on the eth is the async notification of status=success.
> > 
> > The idea was to find out whether the association actually worked and if
> > not either fail the start of the VM or not hotplug the interface. If we
> > don't do that the user may end up having a VM that has no connectivity
> > (depending on how the switch handles an un-associated VM) and start
> > debugging all kinds of things... Really, I would like to know if
> > something went wrong. How long would we have to wait for the status to
> > change? How does a switch handle traffic from a VM if the association
> > failed? At least for 802.1Qbg we were going to get failure notification.
> 
> I tend to agree that we should try to get some indication of whether
> the associate succeeded or failed.  Is the time that we would have to
> poll bounded by anything, or is it reasonably short?  
> 
> Mostly I'm concerned about the failure case: how would the user know
> that something has gone wrong, and where would information to debug
> the problem appear?

We need to worry about the succeess case too if we let this run async
in the background. eg the VM starts and tries todo DHCP and this times
out before its network link is ready. Also upon migration, we need to
be 100% sure the link is ready before we let the new VM run on the dest
host, otherwise it'll suffer a potential network blackout


Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|