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

[Scott Feldman]

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?

I'm worried about scaling if each poll cycle is 10-20 secs.  It's very easy
to have 100+ virtual NICs connected to 100+ virtual ports.  In fact, I can
create that setup today.  Would libvirt serialize the polling, polling one
virtual port and then the next?  If not, then my scaling concern isn't
valid.

-scott