[libvirt] [RFC] [PATCH 3/3 v2] vepa+vsi: Some experimental code for 802.1Qbh
This patch may get 802.1Qbh devices working. I am adding some code to poll for the status of an 802.1Qbh device and loop for a while until the status indicates success. This part for sure needs more work and testing... I am recycling link_dump from a previous patch. Changes from V1 to V2: - Following tree Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> --- src/util/macvtap.c | 116 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) Index: libvirt-acl/src/util/macvtap.c =================================================================== --- libvirt-acl.orig/src/util/macvtap.c +++ libvirt-acl/src/util/macvtap.c @@ -960,6 +960,95 @@ getPortProfileStatus(struct nlmsghdr *nl static int +link_dump(int ifindex, const char *ifname, struct nlattr **tb, + char **recvbuf) +{ + int rc = 0; + char nlmsgbuf[256] = { 0, }; + struct nlmsghdr *nlm = (struct nlmsghdr *)nlmsgbuf, *resp; + struct nlmsgerr *err; + char rtattbuf[64]; + struct rtattr *rta; + struct ifinfomsg i = { + .ifi_family = AF_UNSPEC, + .ifi_index = ifindex + }; + int recvbuflen; + + *recvbuf = NULL; + + nlInit(nlm, NLM_F_REQUEST, RTM_GETLINK); + + if (!nlAppend(nlm, sizeof(nlmsgbuf), &i, sizeof(i))) + goto buffer_too_small; + + if (ifindex < 0 && ifname != NULL) { + rta = rtattrCreate(rtattbuf, sizeof(rtattbuf), IFLA_IFNAME, + ifname, strlen(ifname) + 1); + if (!rta) + goto buffer_too_small; + + if (!nlAppend(nlm, sizeof(nlmsgbuf), rtattbuf, rta->rta_len)) + goto buffer_too_small; + } + + if (nlComm(nlm, recvbuf, &recvbuflen) < 0) + return -1; + + if (recvbuflen < NLMSG_LENGTH(0) || *recvbuf == NULL) + goto malformed_resp; + + resp = (struct nlmsghdr *)*recvbuf; + + switch (resp->nlmsg_type) { + case NLMSG_ERROR: + err = (struct nlmsgerr *)NLMSG_DATA(resp); + if (resp->nlmsg_len < NLMSG_LENGTH(sizeof(*err))) + goto malformed_resp; + + switch (-err->error) { + case 0: + break; + + default: + virReportSystemError(-err->error, + _("error dumping %d interface"), + ifindex); + rc = -1; + } + break; + + case GENL_ID_CTRL: + case NLMSG_DONE: + if (nlmsg_parse(resp, sizeof(struct ifinfomsg), + tb, IFLA_MAX, ifla_policy)) { + goto malformed_resp; + } + break; + + default: + goto malformed_resp; + } + + if (rc != 0) + VIR_FREE(*recvbuf); + + return rc; + +malformed_resp: + macvtapError(VIR_ERR_INTERNAL_ERROR, "%s", + _("malformed netlink response message")); + VIR_FREE(*recvbuf); + return -1; + +buffer_too_small: + macvtapError(VIR_ERR_INTERNAL_ERROR, "%s", + _("internal buffer is too small")); + return -1; +} + + +static int doPortProfileOpSetLink(bool multicast, const char *ifname, int ifindex, const char *profileId, @@ -1151,6 +1240,10 @@ doPortProfileOpCommon(bool multicast, uint8_t op) { int rc; + char *recvbuf = NULL; + struct nlattr *tb[IFLA_MAX + 1]; + int repeats = 5; + uint16_t status; rc = doPortProfileOpSetLink(multicast, ifname, ifindex, @@ -1167,6 +1260,30 @@ doPortProfileOpCommon(bool multicast, return rc; } + if (!multicast) { + /* 802.1Qbh -- query for status */ + while (--repeats) { + rc = link_dump(ifindex, ifname, tb, &recvbuf); + if (rc) + goto err_exit; + rc = getPortProfileStatus((struct nlmsghdr *)recvbuf, &status); + if (rc == 0) { + if (status == 0) + break; + if (status != 0) { + fprintf(stderr,"Current status: %d\n", status); + rc = 1; + } + } + usleep(10000); + + VIR_FREE(recvbuf); + } + } + +err_exit: + VIR_FREE(recvbuf); + return rc; }
On 5/21/10 6:50 AM, "Stefan Berger" <stefanb@linux.vnet.ibm.com> wrote:
This patch may get 802.1Qbh devices working. I am adding some code to poll for the status of an 802.1Qbh device and loop for a while until the status indicates success. This part for sure needs more work and testing...
I think we can drop this patch 3/3. For bh, we don't want to poll for status because it may take awhile before status of other than in-progress is indicated. Link UP on the eth is the async notification of status=success.
I am recycling link_dump from a previous patch.
Changes from V1 to V2: - Following tree
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
--- src/util/macvtap.c | 116 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+)
Index: libvirt-acl/src/util/macvtap.c =================================================================== --- libvirt-acl.orig/src/util/macvtap.c +++ libvirt-acl/src/util/macvtap.c @@ -960,6 +960,95 @@ getPortProfileStatus(struct nlmsghdr *nl
static int +link_dump(int ifindex, const char *ifname, struct nlattr **tb, + char **recvbuf) +{ + int rc = 0; + char nlmsgbuf[256] = { 0, }; + struct nlmsghdr *nlm = (struct nlmsghdr *)nlmsgbuf, *resp; + struct nlmsgerr *err; + char rtattbuf[64]; + struct rtattr *rta; + struct ifinfomsg i = { + .ifi_family = AF_UNSPEC, + .ifi_index = ifindex + }; + int recvbuflen; + + *recvbuf = NULL; + + nlInit(nlm, NLM_F_REQUEST, RTM_GETLINK); + + if (!nlAppend(nlm, sizeof(nlmsgbuf), &i, sizeof(i))) + goto buffer_too_small; + + if (ifindex < 0 && ifname != NULL) { + rta = rtattrCreate(rtattbuf, sizeof(rtattbuf), IFLA_IFNAME, + ifname, strlen(ifname) + 1); + if (!rta) + goto buffer_too_small; + + if (!nlAppend(nlm, sizeof(nlmsgbuf), rtattbuf, rta->rta_len)) + goto buffer_too_small; + } + + if (nlComm(nlm, recvbuf, &recvbuflen) < 0) + return -1; + + if (recvbuflen < NLMSG_LENGTH(0) || *recvbuf == NULL) + goto malformed_resp; + + resp = (struct nlmsghdr *)*recvbuf; + + switch (resp->nlmsg_type) { + case NLMSG_ERROR: + err = (struct nlmsgerr *)NLMSG_DATA(resp); + if (resp->nlmsg_len < NLMSG_LENGTH(sizeof(*err))) + goto malformed_resp; + + switch (-err->error) { + case 0: + break; + + default: + virReportSystemError(-err->error, + _("error dumping %d interface"), + ifindex); + rc = -1; + } + break; + + case GENL_ID_CTRL: + case NLMSG_DONE: + if (nlmsg_parse(resp, sizeof(struct ifinfomsg), + tb, IFLA_MAX, ifla_policy)) { + goto malformed_resp; + } + break; + + default: + goto malformed_resp; + } + + if (rc != 0) + VIR_FREE(*recvbuf); + + return rc; + +malformed_resp: + macvtapError(VIR_ERR_INTERNAL_ERROR, "%s", + _("malformed netlink response message")); + VIR_FREE(*recvbuf); + return -1; + +buffer_too_small: + macvtapError(VIR_ERR_INTERNAL_ERROR, "%s", + _("internal buffer is too small")); + return -1; +} + + +static int doPortProfileOpSetLink(bool multicast, const char *ifname, int ifindex, const char *profileId, @@ -1151,6 +1240,10 @@ doPortProfileOpCommon(bool multicast, uint8_t op) { int rc; + char *recvbuf = NULL; + struct nlattr *tb[IFLA_MAX + 1]; + int repeats = 5; + uint16_t status;
rc = doPortProfileOpSetLink(multicast, ifname, ifindex, @@ -1167,6 +1260,30 @@ doPortProfileOpCommon(bool multicast, return rc; }
+ if (!multicast) { + /* 802.1Qbh -- query for status */ + while (--repeats) { + rc = link_dump(ifindex, ifname, tb, &recvbuf); + if (rc) + goto err_exit; + rc = getPortProfileStatus((struct nlmsghdr *)recvbuf, &status); + if (rc == 0) { + if (status == 0) + break; + if (status != 0) { + fprintf(stderr,"Current status: %d\n", status); + rc = 1; + } + } + usleep(10000); + + VIR_FREE(recvbuf); + } + } + +err_exit: + VIR_FREE(recvbuf); + return rc; }
On Fri, 2010-05-21 at 23:35 -0700, Scott Feldman wrote:
On 5/21/10 6:50 AM, "Stefan Berger" <stefanb@linux.vnet.ibm.com> wrote:
This patch may get 802.1Qbh devices working. I am adding some code to poll for the status of an 802.1Qbh device and loop for a while until the status indicates success. This part for sure needs more work and testing...
I think we can drop this patch 3/3. For bh, we don't want to poll for status because it may take awhile before status of other than in-progress is indicated. Link UP on the eth is the async notification of status=success.
The idea was to find out whether the association actually worked and if not either fail the start of the VM or not hotplug the interface. If we don't do that the user may end up having a VM that has no connectivity (depending on how the switch handles an un-associated VM) and start debugging all kinds of things... Really, I would like to know if something went wrong. How long would we have to wait for the status to change? How does a switch handle traffic from a VM if the association failed? At least for 802.1Qbg we were going to get failure notification. Stefan
On Sat, May 22, 2010 at 11:14:20AM -0400, Stefan Berger wrote:
On Fri, 2010-05-21 at 23:35 -0700, Scott Feldman wrote:
On 5/21/10 6:50 AM, "Stefan Berger" <stefanb@linux.vnet.ibm.com> wrote:
This patch may get 802.1Qbh devices working. I am adding some code to poll for the status of an 802.1Qbh device and loop for a while until the status indicates success. This part for sure needs more work and testing...
I think we can drop this patch 3/3. For bh, we don't want to poll for status because it may take awhile before status of other than in-progress is indicated. Link UP on the eth is the async notification of status=success.
The idea was to find out whether the association actually worked and if not either fail the start of the VM or not hotplug the interface. If we don't do that the user may end up having a VM that has no connectivity (depending on how the switch handles an un-associated VM) and start debugging all kinds of things... Really, I would like to know if something went wrong. How long would we have to wait for the status to change? How does a switch handle traffic from a VM if the association failed? At least for 802.1Qbg we were going to get failure notification.
I tend to agree that we should try to get some indication of whether the associate succeeded or failed. Is the time that we would have to poll bounded by anything, or is it reasonably short? 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? Dave
On 5/22/10 11:34 AM, "Dave Allan" <dallan@redhat.com> wrote:
On Sat, May 22, 2010 at 11:14:20AM -0400, Stefan Berger wrote:
On Fri, 2010-05-21 at 23:35 -0700, Scott Feldman wrote:
On 5/21/10 6:50 AM, "Stefan Berger" <stefanb@linux.vnet.ibm.com> wrote:
This patch may get 802.1Qbh devices working. I am adding some code to poll for the status of an 802.1Qbh device and loop for a while until the status indicates success. This part for sure needs more work and testing...
I think we can drop this patch 3/3. For bh, we don't want to poll for status because it may take awhile before status of other than in-progress is indicated. Link UP on the eth is the async notification of status=success.
The idea was to find out whether the association actually worked and if not either fail the start of the VM or not hotplug the interface. If we don't do that the user may end up having a VM that has no connectivity (depending on how the switch handles an un-associated VM) and start debugging all kinds of things... Really, I would like to know if something went wrong. How long would we have to wait for the status to change? How does a switch handle traffic from a VM if the association failed? At least for 802.1Qbg we were going to get failure notification.
I tend to agree that we should try to get some indication of whether the associate succeeded or failed. Is the time that we would have to poll bounded by anything, or is it reasonably short?
It's difficult to put an upper bound on how long to poll. In most case, status would be available in a reasonably short period of time, but the upper bound depends on activity external to the host.
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). -scott
On Sat, May 22, 2010 at 12:17:05PM -0700, Scott Feldman wrote:
On 5/22/10 11:34 AM, "Dave Allan" <dallan@redhat.com> wrote:
On Sat, May 22, 2010 at 11:14:20AM -0400, Stefan Berger wrote:
On Fri, 2010-05-21 at 23:35 -0700, Scott Feldman wrote:
On 5/21/10 6:50 AM, "Stefan Berger" <stefanb@linux.vnet.ibm.com> wrote:
This patch may get 802.1Qbh devices working. I am adding some code to poll for the status of an 802.1Qbh device and loop for a while until the status indicates success. This part for sure needs more work and testing...
I think we can drop this patch 3/3. For bh, we don't want to poll for status because it may take awhile before status of other than in-progress is indicated. Link UP on the eth is the async notification of status=success.
The idea was to find out whether the association actually worked and if not either fail the start of the VM or not hotplug the interface. If we don't do that the user may end up having a VM that has no connectivity (depending on how the switch handles an un-associated VM) and start debugging all kinds of things... Really, I would like to know if something went wrong. How long would we have to wait for the status to change? How does a switch handle traffic from a VM if the association failed? At least for 802.1Qbg we were going to get failure notification.
I tend to agree that we should try to get some indication of whether the associate succeeded or failed. Is the time that we would have to poll bounded by anything, or is it reasonably short?
It's difficult to put an upper bound on how long to poll. In most case, status would be available in a reasonably short period of time, but the upper bound depends on activity external to the host.
That makes sense. The timeout should be a configurable value. What do you think is a reasonable default?
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. Dave
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. -scott
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? Dave
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?
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
On Sun, 2010-05-23 at 10:37 -0700, Scott Feldman wrote:
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:
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.
I think polling in short intervals of 1/8 second should be ok; maybe with some backoff if nothing happens for 2 seconds or so. There is serialization occurring, but it's not the macvtap (setup) code itself that does the serialization but the code is invoked as part of building the command line for qemu which in turn is called with the qemu_driver lock being held and thus will be serialized due to serialization requirements of other parts. Stefan
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: 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? Let me revisit the polling loop and work it into my patch... -scott
On Sun, May 23, 2010 at 11:26:19AM -0700, Scott Feldman wrote:
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:
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
On Sat, May 22, 2010 at 02:34:33PM -0400, Dave Allan wrote:
On Sat, May 22, 2010 at 11:14:20AM -0400, Stefan Berger wrote:
On Fri, 2010-05-21 at 23:35 -0700, Scott Feldman wrote:
On 5/21/10 6:50 AM, "Stefan Berger" <stefanb@linux.vnet.ibm.com> wrote:
This patch may get 802.1Qbh devices working. I am adding some code to poll for the status of an 802.1Qbh device and loop for a while until the status indicates success. This part for sure needs more work and testing...
I think we can drop this patch 3/3. For bh, we don't want to poll for status because it may take awhile before status of other than in-progress is indicated. Link UP on the eth is the async notification of status=success.
The idea was to find out whether the association actually worked and if not either fail the start of the VM or not hotplug the interface. If we don't do that the user may end up having a VM that has no connectivity (depending on how the switch handles an un-associated VM) and start debugging all kinds of things... Really, I would like to know if something went wrong. How long would we have to wait for the status to change? How does a switch handle traffic from a VM if the association failed? At least for 802.1Qbg we were going to get failure notification.
I tend to agree that we should try to get some indication of whether the associate succeeded or failed. Is the time that we would have to poll bounded by anything, or is it reasonably short?
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?
We need to worry about the succeess case too if we let this run async in the background. eg the VM starts and tries todo DHCP and this times out before its network link is ready. Also upon migration, we need to be 100% sure the link is ready before we let the new VM run on the dest host, otherwise it'll suffer a potential network blackout Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (4)
-
Daniel P. Berrange -
Dave Allan -
Scott Feldman -
Stefan Berger