[Qemu-devel] Question about VM inner route entry's lost when vhost-user reconnect

[Qemu-devel] Question about VM inner route entry's lost when vhost-user reconnect

[Lilijun (Jerry, Cloud Networking)]

Hi all,

      I am running my VM using vhost-user NIC with OVS-DPDK.  The steps of my question is shown as follows:
     1) In the VM, I add one route entry manually on the vNIC eth0 using the linux tool route. 
     2) When restarting openvswitch service for the crash of the ovs-vswitchd, qemu's vhost-user reconnected successfully after 40s.  
     3) Here VM's vNIC will receive link down and up events, the interval between the two events is about 40s.
     3) But that route entry disappeared and that will cause user's network traffic interruption and the service failed.

     Is there some work on this problem?  Can we keep the vNIC's link up status when do vhost-user's reconnecting work?

     Thanks.

Jerry

Re: [Qemu-devel] Question about VM inner route entry's lost when vhost-user reconnect

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

On Mon, Mar 04, 2019 at 08:26:23AM +0000, Lilijun (Jerry, Cloud Networking) wrote:
>       I am running my VM using vhost-user NIC with OVS-DPDK.  The steps of my question is shown as follows:
>      1) In the VM, I add one route entry manually on the vNIC eth0 using the linux tool route. 
>      2) When restarting openvswitch service for the crash of the ovs-vswitchd, qemu's vhost-user reconnected successfully after 40s.  
>      3) Here VM's vNIC will receive link down and up events, the interval between the two events is about 40s.
>      3) But that route entry disappeared and that will cause user's network traffic interruption and the service failed.
> 
>      Is there some work on this problem?  Can we keep the vNIC's link up status when do vhost-user's reconnecting work?

Can you add the custom route to the network management tool inside the
guest so that it will be reinstated when the link comes back up?

The details of how to do this depend on the guest's distro.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] Question about VM inner route entry's lost when vhost-user reconnect

[Lilijun (Jerry, Cloud Networking)]

Hi, Stefan

This problem is related with backend vhost-user socket abnormal cases, we shouldn't ask customers to configure it manually for backend's issues or depends on guest OS's network configuration.

Thanks

> -----Original Message-----
> From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
> Sent: Wednesday, March 06, 2019 6:07 PM
> To: Lilijun (Jerry, Cloud Networking) <jerry.lilijun@huawei.com>
> Cc: qemu-devel@nongnu.org; wangxin (U)
> <wangxinxin.wang@huawei.com>; wangyunjian
> <wangyunjian@huawei.com>
> Subject: Re: [Qemu-devel] Question about VM inner route entry's lost when
> vhost-user reconnect
> 
> On Mon, Mar 04, 2019 at 08:26:23AM +0000, Lilijun (Jerry, Cloud Networking)
> wrote:
> >       I am running my VM using vhost-user NIC with OVS-DPDK.  The steps of
> my question is shown as follows:
> >      1) In the VM, I add one route entry manually on the vNIC eth0 using the
> linux tool route.
> >      2) When restarting openvswitch service for the crash of the ovs-vswitchd,
> qemu's vhost-user reconnected successfully after 40s.
> >      3) Here VM's vNIC will receive link down and up events, the interval
> between the two events is about 40s.
> >      3) But that route entry disappeared and that will cause user's network
> traffic interruption and the service failed.
> >
> >      Is there some work on this problem?  Can we keep the vNIC's link up
> status when do vhost-user's reconnecting work?
> 
> Can you add the custom route to the network management tool inside the
> guest so that it will be reinstated when the link comes back up?
> 
> The details of how to do this depend on the guest's distro.
> 
> Stefan

Re: [Qemu-devel] Question about VM inner route entry's lost when vhost-user reconnect

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

On Fri, Mar 08, 2019 at 02:31:12AM +0000, Lilijun (Jerry, Cloud Networking) wrote:
> This problem is related with backend vhost-user socket abnormal cases, we shouldn't ask customers to configure it manually for backend's issues or depends on guest OS's network configuration.

In Step 1 you said:

> > >      1) In the VM, I add one route entry manually on the vNIC eth0 using the
> > linux tool route.

You configured the route manually inside the guest.  Seems like a guest
problem to me.

If this was a physical machine that lost connectivity due to a link
event, what would happen?

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] Question about VM inner route entry's lost when vhost-user reconnect

[Lilijun (Jerry, Cloud Networking)]

> -----Original Message-----
> From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
> Sent: Monday, March 11, 2019 5:47 PM
> To: Lilijun (Jerry, Cloud Networking) <jerry.lilijun@huawei.com>
> Cc: qemu-devel@nongnu.org; wangxin (U)
> <wangxinxin.wang@huawei.com>; wangyunjian
> <wangyunjian@huawei.com>
> Subject: Re: [Qemu-devel] Question about VM inner route entry's lost when
> vhost-user reconnect
> 
> On Fri, Mar 08, 2019 at 02:31:12AM +0000, Lilijun (Jerry, Cloud Networking)
> wrote:
> > This problem is related with backend vhost-user socket abnormal cases, we
> shouldn't ask customers to configure it manually for backend's issues or
> depends on guest OS's network configuration.
> 
> In Step 1 you said:
> 
> > > >      1) In the VM, I add one route entry manually on the vNIC eth0
> > > > using the
> > > linux tool route.
> 
> You configured the route manually inside the guest.  Seems like a guest
> problem to me.
> 
> If this was a physical machine that lost connectivity due to a link event, what
> would happen?

Yes, the configuration can be recovered manually by customers.

But in the virtualization machines, this configuration's lost is a result of backend process's software unexpected bugs or version update. So I think we need hide this change to customers.
> 
> Stefan