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

[Scott Feldman]

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.

-scott