[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On 5/23/10 6:41 AM, "Dave Allan" <dallan 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 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:


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.

the macvtap.

Sound OK?

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]