Re: [libvirt] [RFC] [PATCH 3/3 v2] vepa+vsi: Some experimental code for 802.1Qbh
On Sun, May 23, 2010 at 11:26:19AM -0700, Scott Feldman wrote:
On 5/23/10 6:41 AM, "Dave Allan" <dallan(a)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(a)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