On 04/28/2017 07:23 PM, Joel Wirāmu Pauling wrote: > Possibly related I notice race conditions caused by vnic never getting > loaded if an existing bridge is already up (by OS init scripts etc) and > stopping VM's from getting started. Can you explain this more exactly? In particular, by "vnic" do you mean the network device as seen by the guest? And what do you mean by the term "getting loaded"? (It doesn't make sense to me that you should mean the network device in the guest, unless "stopping VM's from getting started" just means that the guest doesn't become fully functional, rather than that the qemu process doesn't start). Beyond that, of course the bridge that the tap device will be connected to needs to exist before you can connect something to it - I don't understand how its existence could cause a failure; rather its *non*-existence would cause a failure. (As you can see by my wild suppositions that make no sense, the terms you've used are a bit too vague/open to interpretation for me to understand exactly the problem you're referring to) (Hmm - perhaps you're referring to the situation where libvirt attempts to create a bridge on the host for one of its virtual networks, but either a bridge by that name has already been created by "someone else" or another netdev already exists on the host that is on the same subnet (and thus has the same route)? Your description doesn't fit that very well, but that is a known problem and unrelated to the patch/problem we're discussing here. > > Often this is behavior you want ; i.e having Host Hypervisor NIC's added > and up before libvirtd sets up it's nics/bridges. > > > On 29 April 2017 at 11:15, <lu.zhipeng@xxxxxxxxxx > <mailto:lu.zhipeng@xxxxxxxxxx>> 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. > > i have done some tests for a tap + openvswitch bridge network. i > find the nic named "vnet0" don't exsit before calling > the virNetDevOpenvswitchRemovePort. > > i think the tap is deleted not by removingport from bridge. i > think hotpluging net has the same problem. > > > by the way: > > my company's e-mail does not support thread posting and has > some other problems. i believe that my colleagues can soon resloved > them. > > > > > > > *为了让您的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 <mailto:lu.zhipeng@xxxxxxxxxx> > www.zte.com.cn <http://www.zte.com.cn/> > > 原始邮件 > *发件人：*＜berrange@xxxxxxxxxx <mailto:berrange@xxxxxxxxxx>＞; > *收件人：*芦志朋10108272; > *抄送人：*＜libvir-list@xxxxxxxxxx <mailto:libvir-list@xxxxxxxxxx>＞; > *日 期 ：*2017年04月28日 19:27 > *主 题 ：**Re: [PATCH] qemu: change the name of tap device > for a tapand bridge network* > > > 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. > > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange > <https://www.flickr.com/photos/dberrange> :| > |: https://libvirt.org -o- https://fstop138.berrange.com > <https://fstop138.berrange.com> :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange > <https://www.instagram.com/dberrange> :| > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx <mailto:libvir-list@xxxxxxxxxx> > https://www.redhat.com/mailman/listinfo/libvir-list > <https://www.redhat.com/mailman/listinfo/libvir-list> > > > > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx <mailto:libvir-list@xxxxxxxxxx> > https://www.redhat.com/mailman/listinfo/libvir-list > <https://www.redhat.com/mailman/listinfo/libvir-list> > > > > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
