I'll try and explain the steps/situation where this is an issue.
Say for example you have your router/dhcpd done inside a VM guest - you use macvtap devices and vlans off the hypervisor to get the traffic in and out (WAN and LAN). And you want the LAN side to provide connectivity to the host as well as to the network beyond the host.
this is on a Ubuntu 16.04 host.
this is on a Ubuntu 16.04 host.
1) Create and isolated virtual Network via libvirt xml - say 'LAN' this is the second network (assume default exists) creates virbr1 and a vnic1 This is addition to the WAN and LAN macvtap devices. Unbeknown-st to libvirt the LAN macvtap is going to end up bridge to the 'isolated' network by the VM.
2) the virbr1 bridge needs numbering
vnic1 is attached inside the VM to a dhcpd server but you still need the virbr1 interface to be numbered on the hypervisor (but you don't want the libvirt networking to take care of the numbering etc becuase that's what your fancy NFV VM is going to handle). Manually it's easy at this point you just run dhclient et.al on the bridge and you are good to go.
BUT you want this to happen at boot; adding any sort of etc/network or /etc/sysconfig/networking scripts refering to that virbr1 will create a race condition which will stop the vm from getting started as you mention.
On 29 April 2017 at 14:45, Laine Stump <laine@xxxxxxxxx> wrote:
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: > *为了让您的VPlat虚拟化故障得到高效的处理，
>
>
> ＞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技术支
> 持。*
>
> 芦志朋 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> :| > libvir-list@xxxxxxxxxx <mailto:libvir-list@xxxxxxxxxx
> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange
> <https://www.instagram.com/dberrange > :|
>
> --
> libvir-list mailing list
>
> 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
