Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1391681 > unrolled thread

Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover Greg KH <gregkh@linuxfoundation.org> - 2016-04-30 23:10 +0200
    RE: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover KY Srinivasan <kys@microsoft.com> - 2016-04-30 23:50 +0200
      Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover Greg KH <gregkh@linuxfoundation.org> - 2016-05-01 00:00 +0200
        RE: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover KY Srinivasan <kys@microsoft.com> - 2016-05-01 02:30 +0200

#1391681 — Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover

On Tue, Apr 05, 2016 at 04:57:40PM -0700, K. Y. Srinivasan wrote:
> From: Vitaly Kuznetsov <vkuznets@redhat.com>
> 
> Hyper-V VMs can be replicated to another hosts and there is a feature to
> set different IP for replicas, it is called 'Failover TCP/IP'. When
> such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon
> as we finish negotiation procedure. The problem is that it can happen (and
> it actually happens) before userspace daemon connects and we reply with
> HV_E_FAIL to the message. As there are no repetitions we fail to set the
> requested IP.
> 
> Solve the issue by postponing our reply to the negotiation message till
> userspace daemon is connected. We can't wait too long as there is a
> host-side timeout (cca. 75 seconds) and if we fail to reply in this time
> frame the whole KVP service will become inactive. The solution is not
> ideal - if it takes userspace daemon more than 60 seconds to connect
> IP Failover will still fail but I don't see a solution with our current
> separation between kernel and userspace parts.
> 
> Other two modules (VSS and FCOPY) don't require such delay, leave them
> untouched.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
>  drivers/hv/hv_kvp.c       |   31 +++++++++++++++++++++++++++++++
>  drivers/hv/hyperv_vmbus.h |    5 +++++
>  2 files changed, 36 insertions(+), 0 deletions(-)

This series doesn't apply to my tree :(

[toc] | [next] | [standalone]

#1391703

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Saturday, April 30, 2016 2:05 PM
> To: KY Srinivasan <kys@microsoft.com>
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com;
> jasowang@redhat.com
> Subject: Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover
> 
> On Tue, Apr 05, 2016 at 04:57:40PM -0700, K. Y. Srinivasan wrote:
> > From: Vitaly Kuznetsov <vkuznets@redhat.com>
> >
> > Hyper-V VMs can be replicated to another hosts and there is a feature to
> > set different IP for replicas, it is called 'Failover TCP/IP'. When
> > such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as
> soon
> > as we finish negotiation procedure. The problem is that it can happen (and
> > it actually happens) before userspace daemon connects and we reply with
> > HV_E_FAIL to the message. As there are no repetitions we fail to set the
> > requested IP.
> >
> > Solve the issue by postponing our reply to the negotiation message till
> > userspace daemon is connected. We can't wait too long as there is a
> > host-side timeout (cca. 75 seconds) and if we fail to reply in this time
> > frame the whole KVP service will become inactive. The solution is not
> > ideal - if it takes userspace daemon more than 60 seconds to connect
> > IP Failover will still fail but I don't see a solution with our current
> > separation between kernel and userspace parts.
> >
> > Other two modules (VSS and FCOPY) don't require such delay, leave them
> > untouched.
> >
> > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> >  drivers/hv/hv_kvp.c       |   31 +++++++++++++++++++++++++++++++
> >  drivers/hv/hyperv_vmbus.h |    5 +++++
> >  2 files changed, 36 insertions(+), 0 deletions(-)
> 
> This series doesn't apply to my tree :(

Looks like you have already applied most of the patches in this series. I will resend what is not applied.

Thanks,

K. Y

[toc] | [prev] | [next] | [standalone]

#1391704

On Sat, Apr 30, 2016 at 09:43:09PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Saturday, April 30, 2016 2:05 PM
> > To: KY Srinivasan <kys@microsoft.com>
> > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com;
> > jasowang@redhat.com
> > Subject: Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover
> > 
> > On Tue, Apr 05, 2016 at 04:57:40PM -0700, K. Y. Srinivasan wrote:
> > > From: Vitaly Kuznetsov <vkuznets@redhat.com>
> > >
> > > Hyper-V VMs can be replicated to another hosts and there is a feature to
> > > set different IP for replicas, it is called 'Failover TCP/IP'. When
> > > such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as
> > soon
> > > as we finish negotiation procedure. The problem is that it can happen (and
> > > it actually happens) before userspace daemon connects and we reply with
> > > HV_E_FAIL to the message. As there are no repetitions we fail to set the
> > > requested IP.
> > >
> > > Solve the issue by postponing our reply to the negotiation message till
> > > userspace daemon is connected. We can't wait too long as there is a
> > > host-side timeout (cca. 75 seconds) and if we fail to reply in this time
> > > frame the whole KVP service will become inactive. The solution is not
> > > ideal - if it takes userspace daemon more than 60 seconds to connect
> > > IP Failover will still fail but I don't see a solution with our current
> > > separation between kernel and userspace parts.
> > >
> > > Other two modules (VSS and FCOPY) don't require such delay, leave them
> > > untouched.
> > >
> > > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > ---
> > >  drivers/hv/hv_kvp.c       |   31 +++++++++++++++++++++++++++++++
> > >  drivers/hv/hyperv_vmbus.h |    5 +++++
> > >  2 files changed, 36 insertions(+), 0 deletions(-)
> > 
> > This series doesn't apply to my tree :(
> 
> Looks like you have already applied most of the patches in this series. I will resend what is not applied.

If this was a "resend", why didn't it show that in the patch
description?

[toc] | [prev] | [next] | [standalone]

#1391724

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Saturday, April 30, 2016 2:54 PM
> To: KY Srinivasan <kys@microsoft.com>
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com;
> jasowang@redhat.com
> Subject: Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover
> 
> On Sat, Apr 30, 2016 at 09:43:09PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Saturday, April 30, 2016 2:05 PM
> > > To: KY Srinivasan <kys@microsoft.com>
> > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com;
> > > jasowang@redhat.com
> > > Subject: Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover
> > >
> > > On Tue, Apr 05, 2016 at 04:57:40PM -0700, K. Y. Srinivasan wrote:
> > > > From: Vitaly Kuznetsov <vkuznets@redhat.com>
> > > >
> > > > Hyper-V VMs can be replicated to another hosts and there is a feature
> to
> > > > set different IP for replicas, it is called 'Failover TCP/IP'. When
> > > > such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message
> as
> > > soon
> > > > as we finish negotiation procedure. The problem is that it can happen
> (and
> > > > it actually happens) before userspace daemon connects and we reply
> with
> > > > HV_E_FAIL to the message. As there are no repetitions we fail to set
> the
> > > > requested IP.
> > > >
> > > > Solve the issue by postponing our reply to the negotiation message till
> > > > userspace daemon is connected. We can't wait too long as there is a
> > > > host-side timeout (cca. 75 seconds) and if we fail to reply in this time
> > > > frame the whole KVP service will become inactive. The solution is not
> > > > ideal - if it takes userspace daemon more than 60 seconds to connect
> > > > IP Failover will still fail but I don't see a solution with our current
> > > > separation between kernel and userspace parts.
> > > >
> > > > Other two modules (VSS and FCOPY) don't require such delay, leave
> them
> > > > untouched.
> > > >
> > > > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > ---
> > > >  drivers/hv/hv_kvp.c       |   31 +++++++++++++++++++++++++++++++
> > > >  drivers/hv/hyperv_vmbus.h |    5 +++++
> > > >  2 files changed, 36 insertions(+), 0 deletions(-)
> > >
> > > This series doesn't apply to my tree :(
> >
> > Looks like you have already applied most of the patches in this series. I will
> resend what is not applied.
> 
> If this was a "resend", why didn't it show that in the patch
> description?

My fault; sorry for the confusion. Greg, I am going to resend all the 
patches yet to be committed with the right "resend" tag.

Regards,

K. Y

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web