FYI your replies to messages on the list are almost impossible to read & understand. Your email client is sending HTML and badly mangled plain text. Please make it send plain text only to public mailing lists, with line wrapping and sensibly trim & quote text you are replying to. I can't see any comment you made in this latest message so I can't reply to you. On Tue, May 09, 2017 at 08:44:55AM +0800, lu.zhipeng@xxxxxxxxxx wrote: > On Mon, May 08, 2017 at 03:03:30PM +0800, ZhiPeng Lu wrote:＞＞ In qemuProcessStop we explicitly remove the port from the openvswitch bridge after＞＞ qemuProcessKill is called. But there is a certain interval of time between＞＞ deleting tap device and removing it from bridge. The problem occurs when two vms＞＞ start and shutdown with the same name's network interface attached to the same＞＞ openvswitch bridge. When one vm with the nic named "vnet0" stopping, it deleted＞＞tap device without timely removing the port from bridge.＞＞.At this time, another vm created the tap device named "vnet0" and added port to the＞＞ same bridge. Then, the first vm removed the port from the same bridge.＞＞ Finally, the tap device of the second vm did not attached to the bridge.＞＞ We need to delete the bridge port before deleting the tap device instead of after.＞＞ So what's needed is to move the loop in qemuProcessStop that cleans up＞＞ network interfaces so that it happens before qemuProcessKill is called.＞This fix won't work correctly either. You cannot assume that libvirt has＞control over when the QEMU process exits. It may exit itself *before*＞libvirt runs any of its cleanup code. > > > > > On Mon, May 08, 2017 at 06:18:25PM +0800, lu.zhipeng@xxxxxxxxxx wrote:＞ I may not have described it clearly. ＞ ＞ i need to ensure the order of adding port to bridge and deleting from bridge.＞ ＞ i rename tap device to avoid the problem in my first patch.i think it can solve the problem.＞ ＞ my second patch may can't resolve the problem .＞ ＞ Do you have any better ideas? > > > > > > > > > > > > > g> > > > > > > 为了让您的VPlat虚拟化故障得到高效的处理，请上报故障到: $VPlat技术支持。 > > > 芦志朋 luzhipeng > > > > > > > IT开发工程师 IT Development > Engineer > 操作系统产品部/中心研究院/系统产品 OS Product Dept./Central R＆D Institute/System Product > > > > > > > > > > 深圳市南山区科技南路55号中兴通讯研发大楼33楼 > 33/F, R&D Building, ZTE > Corporation Hi-tech Road South, > Hi-tech > Industrial Park Nanshan District, Shenzhen, P.R.China, 518057 > T: +86 755 xxxxxxxx F:+86 755 xxxxxxxx > M: +86 xxxxxxxxxxx > E: lu.zhipeng@xxxxxxxxxx > www.zte.com.cn > > > > > > > 原始邮件 > > > > 发件人： ＜berrange@xxxxxxxxxx＞ > 收件人： ＜laine@xxxxxxxxx＞ > 抄送人： ＜libvir-list@xxxxxxxxxx＞芦志朋10108272 > 日 期 ：2017年05月02日 16:41 > 主 题 ：Re: [PATCH] qemu: change the name of tap device for a tapand bridge network > > > > > > On Fri, Apr 28, 2017 at 01:08:45PM -0400, Laine Stump wrote: > ＞ On 04/28/2017 05:33 AM, Daniel P. Berrange wrote: > ＞ ＞ On Fri, Apr 28, 2017 at 05:23:19PM +0800, ZhiPeng Lu wrote: > ＞ ＞＞ Creating tap device and adding the device to bridge are not atomic operation. > ＞ ＞＞ Similarly deleting tap device and removing it from bridge are not atomic operation. > ＞ ＞＞ The Problem occurs when two vms start and shutdown. When one vm with the nic > ＞ ＞＞ named "vnet0" stopping, it deleted tap device but not removing port from bridge. > ＞ ＞＞ At this time, another vm created the tap device named "vnet0" and added port to the > ＞ ＞＞ same bridge. Then, the first vm deleted the tap device from the same bridge. > ＞ ＞＞ Finally, the tap device of the second vm don't attached to the bridge. > ＞ ＞＞ So, we can add domid to vm's nic name. For example, the vm's domid is 1 and vnet0 > ＞ ＞＞ is renamed to vnet1.0. > ＞ ＞ > ＞ ＞ Surely deleting the NIC automatically removes it from the bridge so we > ＞ ＞ can just remove the code that delets the bridge port. > ＞ > ＞ That is true when using a Linux host bridge, but I recall that for > ＞ openvswitch (which I think is what ZhiPeng is using, based on an earlier > ＞ patch), you must explicitly remove the port from the bridge - apparently > ＞ the port is still there in openvswitch's table as some sort of "zombie" > ＞ connection even after the tap device itself no longer exists. > ＞ > ＞ > ＞ But instead of changing the naming scheme, maybe we should just delete > ＞ the bridge port *before* deleting the tap device instead of after. (Am I > ＞ recalling correctly that the tap device is deleted automatically when > ＞ the qemu process is killed? If so, then what's needed is to move the > ＞ loop in qemuProcessStop() that cleans up network interfaces so that it > ＞ happens before qemuProcessKill() is called. > > Agreed, we should just reverse the order. > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
