On 5/23/10 6:41 AM, "Dave Allan" <dallan@xxxxxxxxxx> wrote: > On Sat, May 22, 2010 at 06:47:19PM -0700, Scott Feldman wrote: >> On 5/22/10 6:24 PM, "Dave Allan" <dallan@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list