On Sat, May 22, 2010 at 12:17:05PM -0700, Scott Feldman wrote: > On 5/22/10 11:34 AM, "Dave Allan" <dallan@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> 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? > > It's difficult to put an upper bound on how long to poll. In most case, > status would be available in a reasonably short period of time, but the > upper bound depends on activity external to the host. That makes sense. The timeout should be a configurable value. What do you think is a reasonable default? > > 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? > > Think of it as equivalent to waiting to get link UP after plugging in a > physical cable into a physical switch port. In some cases negotiation of > the link may take on the order of seconds. Depends on the physical media, > of course. A user can check for link UP using ethtool or ip cmd. > Similarly, a user can check for association status using ip cmd, once we > extend ip cmd to know about virtual ports (patch for ip cmd coming soon). That's the way I was thinking about it as well. The difference I see between an actual physical cable and what we're doing here is that if you're in the data center and you plug in a cable, you're focused on whether the link comes up. Here, the actor is likely to be an automated process, and users will simply be presented with a VM with no or incorrect connectivity, and they will have no idea what happened. It's just not supportable to provide them with no indication of what failed or why. Dave -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list