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

[Dave Allan]

On Sun, May 23, 2010 at 11:26:19AM -0700, Scott Feldman wrote:
> 
> 
> 
> On 5/23/10 6:41 AM, "Dave Allan" <dallan at redhat.com> wrote:
> 
> > On Sat, May 22, 2010 at 06:47:19PM -0700, Scott Feldman wrote:
> >> On 5/22/10 6:24 PM, "Dave Allan" <dallan at redhat.com> wrote:
> >> 
> >>>>> 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.
> >> 
> >> What can we do in libvirt to provide async status of port-profile
> >> association?  How could an aynsc status be reported to the user via libvirt?
> >> In the virt-manager GUI, for example, on the details sheet for the NICs, can
> >> we display the status of the backing virtual port?  Kind of like the status
> >> on the basic details overview sheet.  Actually, if we could display the
> >> other virtual port settings like port-profile name of VSI-* tuple along with
> >> status, then the user would have some good info to start troubleshooting.
> > 
> > It's not impossible to do what you're suggesting here, but what's the
> > benefit?  Is it a problem to poll for even 10 or 20 seconds?
> 
> These are the return codes from GETLINK for port-profile:
> 
>         PORT_PROFILE_RESPONSE_SUCCESS
>         PORT_PROFILE_RESPONSE_INPROGRESS
>         PORT_PROFILE_RESPONSE_INVALID
>         PORT_PROFILE_RESPONSE_BADSTATE
>         PORT_PROFILE_RESPONSE_INSUFFICIENT_RESOURCES
>         PORT_PROFILE_RESPONSE_ERROR
> 
> In the polling loop, we need to treat INPROGRESS as not an error, even if
> polling loop expires.  In the case of INPROGRESS, when we exit the polling
> loop we can log an informative msg that the association is in progress, but
> not return an error such that the macvtap gets torn down.
> 
> SUCCESS would break from polling loop and not log any msg.
> 
> INVALID|BADSTATE|INSUFFICIENT_RESOURCES|ERROR would log an err msg and abort
> the macvtap.
> 
> Sound OK?

That sounds reasonable to me.

> Let me revisit the polling loop and work it into my patch...

Ok, sounds good; wrt your concerns about scaling, I don't think we
need to poll at high frequency.  I'd also make the poll interval
runtime configurable so it can be tweaked to suit users' needs.

As you can probably tell, I'm not considering this operation as
extremely time sensitive, and I'm also assuming that the normal case
is that this is a quick operation.  I think the things affected are
things like booting a VM, where adding a few seconds in a bad case
scenario isn't going to be catastrophic.  Do you see any use cases in
which a several second addition of time would be a problem, e.g., it
would cause several seconds of downtime to a running VM?  I presume
that in the migrate case that this operation will be completed prior
to the start of the migration.

Dave