qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Question about VM virtio device's link down delay when


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Question about VM virtio device's link down delay when vhost-user reconnect
Date: Mon, 4 Mar 2019 21:39:15 -0500

On Mon, Mar 04, 2019 at 11:46:32AM +0000, Lilijun (Jerry, Cloud Networking) 
wrote:
> 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 
> "route add default gw 192.168.1.2". 
>      2) If openvswitch service was restarted, or the process ovs-vswitchd was 
> aborted, the new process may be started successfully after long seconds such 
> as 40s for the initialization of DPDK huge page memory.
>      3) And Qemu's vhost-user closed the connection and reconnected 
> successfully after 40s.  
>      4) Here VM's vNIC will receive link down and up events, the interval 
> between the two events is about 40s.
>      5) Then I found that route entry disappeared unexpectedly. This will 
> cause some network traffic problems.
> 
>      I have an idea about this problem. We can add a parameter " 
> link_down_delay" for all virtio devices that use vhost-user socket such as 
> virtio-net and virtio-blk. 
> 
>     If vhost-user socket get a connection closed event when the backend 
> process was aborted or restarted, we don't notify VM virtio-net device link 
> down right now.
>    When the vhost-user backend recover this socket's connections before the 
> time of "link_down_delay" ms passed, we need not do that link down 
> notification to VM.
>    Or else, if that's timeout, VM can be notified the link down event as 
> before.
> 
>     Is there any other opinions about this solution?  Or some better ideas? 
> Thanks.
> 
> B.R.
> 
> Jerry
> 

Rather than hardcode a specific timeout policy, I would go further and
start with an option to just hide disconnects from guest completely.
Instead add commands to monitor status of connection and events to
report changes.  Management tools can then mirror connection status to
link if they want to.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]