[libvirt] 答复: Re: [PATCH] qemu: change the name of tap device for a tapand bridge network
Joel Wirāmu Pauling
joel at aenertia.net
Sat Apr 29 03:20:23 UTC 2017
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.
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 at laine.org> 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 at zte.com.cn
> > <mailto:lu.zhipeng at zte.com.cn>> 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 at zte.com.cn <mailto:lu.zhipeng at zte.com.cn>
> > www.zte.com.cn <http://www.zte.com.cn/>
> >
> > 原始邮件
> > *发件人：*＜berrange at redhat.com <mailto:berrange at redhat.com>＞;
> > *收件人：*芦志朋10108272;
> > *抄送人：*＜libvir-list at redhat.com <mailto:libvir-list at redhat.com>＞;
> > *日 期 ：*2017年04月28日 19:27
> > *主 题 ：**Re: [libvirt] [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 at redhat.com <mailto:libvir-list at redhat.com>
> > https://www.redhat.com/mailman/listinfo/libvir-list
> > <https://www.redhat.com/mailman/listinfo/libvir-list>
> >
> >
> >
> >
> > --
> > libvir-list mailing list
> > libvir-list at redhat.com <mailto:libvir-list at redhat.com>
> > https://www.redhat.com/mailman/listinfo/libvir-list
> > <https://www.redhat.com/mailman/listinfo/libvir-list>
> >
> >
> >
> >
> > --
> > libvir-list mailing list
> > libvir-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/libvir-list
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170429/12c0264f/attachment-0001.htm>
More information about the libvir-list
mailing list